Hi all, I have finally updated our kernel trees to
letux-4.14.70 letux-4.18.8 letux-4.19-rc4
and as usual there are binaries and sources at the known locations.
Regarding 4.19-rc4 we have quite some construction sites, unfortunately with some regressions.
Here is the list of (significantly) broken things that I am aware of:
Pyra: * OMAP5 TILER is no longer scanning through the frame buffer and appears to fetch from a fixed address * "reboot" hangs if timer8 is in use * bq2429x charger driver is far from being perfect (sometimes does not detect USB unplug/replug and charging does not start) * AESS does not load firmware and even without, audio is broken * PVR/SGX integration is missing * sd/eMMC switch driver is missing
GTA04: * camera driver is still not stable and incomplete * PVR/SGX integration is incomplete
Others: * Pandora WLAN is broken * Pandora Audio is missing * problems with generic-adc-battery (unreliable readings, % report less precise than it could be) * Udoo neo: no HDMI driver
So all this needs help and support from our community.
BR, Nikolaus
At 08:30 +0200 on Tuesday 2018-09-18, H. Nikolaus Schaller wrote:
So all this needs help and support from our community.
For those who might help, it might be useful to have a primer on getting started. For me there are two questions:
Q1: Please can you clarify (perhaps, if appropriate, on one or more of the following web sites (rather than have the answer buried here in the list)) where the source code for the Pyra lives.
I am confused between the following sites:
http://download.goldelico.com/letux-kernel/ http://projects.goldelico.com/p/gta04-kernel/ https://dev.pyra-handheld.com (requires an account?)
At 08:30 +0200 on Tuesday 2018-09-18, H. Nikolaus Schaller wrote:
Regarding 4.19-rc4 we have quite some construction sites, unfortunately with some regressions.
Here is the list of (significantly) broken things that I am aware of:
Pyra:
- OMAP5 TILER is no longer scanning through the frame buffer and appears to fetch from a fixed address
- "reboot" hangs if timer8 is in use
- bq2429x charger driver is far from being perfect (sometimes does not
detect USB unplug/replug and charging does not start)
- AESS does not load firmware and even without, audio is broken
- PVR/SGX integration is missing
- sd/eMMC switch driver is missing
Q2: For each of the above, which code is likely suspect * Upstream Linux? * Letux patches to upstream Linux? * Pyra-project-specific code or configuration files? * TI OMAP drivers with source code and a free licence? * TI blobs?
And if the TI code or blobs don't live in the main repository, where are they?
Thanks.
N.
Hi,
Am 18.09.2018 um 19:04 schrieb N. Jackson nljlistbox2@gmail.com:
At 08:30 +0200 on Tuesday 2018-09-18, H. Nikolaus Schaller wrote:
So all this needs help and support from our community.
For those who might help, it might be useful to have a primer on getting started. For me there are two questions:
Yes, I am happy to answer all such questions (knowledge sharing/transfer is always good).
Q1: Please can you clarify (perhaps, if appropriate, on one or more of the following web sites (rather than have the answer buried here in the list)) where the source code for the Pyra lives.
I am confused between the following sites:
^^^ this is an archive of precompiled binaries and links into the git repo It is useful to temporarily install older kernels for comparisons.
And it is the repository where the makesd script looks for binary kernels when baking an SD card.
The PyraOS has a different approach and repository. There, kernel tree snapshots are taken and compiled with a root file system into complete Debian SD images for installation by dd.
^^^ this is the Letux Kernel project description where development takes place it provides some resources, e.g. a how-to and links to the source code:
http://projects.goldelico.com/p/gta04-kernel/doc/
But beware, this project is not only for Pyra and has a lot of information for other devices that are supported. It exists because the general problems of other devices are almost the same and they sometimes share solutions (e.g. some device drivers).
https://dev.pyra-handheld.com (requires an account?)
I don't use this resource. I think it is for user-space PyraOS, but someone else should comment on this.
So some source of confusion is that low level development (U-Boot, Kernel) is part of the LetuxOS project but what the user sees (PyraOS) is a separate project that cherry-picks some parts of LetuxOS.
This is also the reason why two mailing lists exits.
At 08:30 +0200 on Tuesday 2018-09-18, H. Nikolaus Schaller wrote:
Regarding 4.19-rc4 we have quite some construction sites, unfortunately with some regressions.
Here is the list of (significantly) broken things that I am aware of:
Pyra:
- OMAP5 TILER is no longer scanning through the frame buffer and appears to fetch from a fixed address
- "reboot" hangs if timer8 is in use
- bq2429x charger driver is far from being perfect (sometimes does not
detect USB unplug/replug and charging does not start)
- AESS does not load firmware and even without, audio is broken
- PVR/SGX integration is missing
- sd/eMMC switch driver is missing
Q2: For each of the above, which code is likely suspect
- Upstream Linux?
Sometimes the problem is upstream (or introduced by API changes not properly matched in our patches), so you don't know before anaylsing and finding the root cause.
- Letux patches to upstream Linux?
Most of these features are not at all upstream, but it may be the interaction with mainline code which is the problem. Sometimes a new driver reveals a bug in mainline (which was not found because some combination wasn't used by anybody else).
For example the TILER did work up to 4.18.x but is broken since 4.19-rc1. There was some manual rebase conflict resolution involved, so it might be a bug introduced by that. Or it might be a new API mismatch.
In most cases these functional areas are in separate patch sets based on latest mainline release (e.g. 4.19-rc4).
Here are some: http://git.goldelico.com/?p=letux-kernel.git;a=shortlog;h=refs/heads/work/le... http://git.goldelico.com/?p=letux-kernel.git;a=shortlog;h=refs/heads/work/hn... http://git.goldelico.com/?p=letux-kernel.git;a=shortlog;h=refs/heads/work/le...
- Pyra-project-specific code or configuration files?
Rarely, but can't be excluded.
- TI OMAP drivers with source code and a free licence?
We have merged all TI open source code (SGX, AESS) into the Letux tree.
E.g.
http://git.goldelico.com/?p=letux-kernel.git;a=commit;h=9a726477e3832f6e5e3c... http://git.goldelico.com/?p=letux-kernel.git;a=shortlog;h=refs/heads/work/le...
- TI blobs?
And if the TI code or blobs don't live in the main repository, where are they?
Well, in most cases finding answers to these questions is part of the task to be done :)
The SGX blobs are also known. And for AESS Marek has tried to rebuild them but did not find time to succeed.
BR, Nikolaus
On Mi, 2018-09-19 at 11:03 +0200, H. Nikolaus Schaller wrote:
Well, I'm a bit confused myself here, so maybe aTc can shed some light here.
Here's what I know:
The Pyra uses a Debian-Base OS with Pyra-specific addons (as packages).
The source for the packages can be found on https://dev.pyra-handheld.com
As far as I am aware, aTc uses the Letux kernel with a few patches and a different config... but I have no idea where these are available :/
There is also a linux-image GIT... but that seems outdated, so I don't think it's this he's using: https://dev.pyra-handheld.com/packages/linux-image-pyra
There's also a U-Boot source, but I'm not sure this is exactly what aTc uses: https://dev.pyra-handheld.com/notaz/pyra-u-boot
Maybe he can let us know :)
https://dev.pyra-handheld.com (requires an account?)
I don't use this resource. I think it is for user-space PyraOS, but someone else should comment on this.
It's mainly for everything related to the Pyra OS, yes. It should contain everything needed to recreate the Debian incl. bootloader and the kernel from scratch.
All packages are there, but it seems the kernel and U-Boot are mising. aTc: Any reason you can't push the kernel / U-Boot sources you're compiling to git?
The GIT doesn't need an account - unless you want to push updates. Simply click on "Explore" at the bottom and choose "All" to see all public projects on the GIT.
So some source of confusion is that low level development (U-Boot, Kernel) is part of the LetuxOS project but what the user sees (PyraOS) is a separate project that cherry-picks some parts of LetuxOS.
To my knowledge, we would use the complete Letux kernel if it fullfilled everything we need (dbp needs aufs in the kernel, which isn't included).
For example the TILER did work up to 4.18.x but is broken since 4.19-rc1. There was some manual rebase conflict resolution involved, so it might be a bug introduced by that. Or it might be a new API mismatch.
Was it really working or simply not complaining when compiling?
Because with the PyraOS, rotation worked fine with Kernel 4.15, but with 4.18, the framebuffer showed a black picture as soon as we enabled TILER rotation.
Without rotation, the framebuffer worked.
Hi all,
Am 20.09.2018 um 00:46 schrieb Michael Mrozek EvilDragon@openpandora.org:
On Mi, 2018-09-19 at 11:03 +0200, H. Nikolaus Schaller wrote:
Well, I'm a bit confused myself here, so maybe aTc can shed some light here.
Here's what I know:
The Pyra uses a Debian-Base OS with Pyra-specific addons (as packages).
The source for the packages can be found on https://dev.pyra-handheld.com
As far as I am aware, aTc uses the Letux kernel with a few patches and a different config... but I have no idea where these are available :/
Yes, I'd like to add the pyra_defconfig to the Letux kernel tree.
There is also a linux-image GIT... but that seems outdated, so I don't think it's this he's using: https://dev.pyra-handheld.com/packages/linux-image-pyra
There's also a U-Boot source, but I'm not sure this is exactly what aTc uses: https://dev.pyra-handheld.com/notaz/pyra-u-boot
Maybe he can let us know :)
https://dev.pyra-handheld.com (requires an account?)
I don't use this resource. I think it is for user-space PyraOS, but someone else should comment on this.
It's mainly for everything related to the Pyra OS, yes. It should contain everything needed to recreate the Debian incl. bootloader and the kernel from scratch.
All packages are there, but it seems the kernel and U-Boot are mising. aTc: Any reason you can't push the kernel / U-Boot sources you're compiling to git?
The GIT doesn't need an account - unless you want to push updates. Simply click on "Explore" at the bottom and choose "All" to see all public projects on the GIT.
So some source of confusion is that low level development (U-Boot, Kernel) is part of the LetuxOS project but what the user sees (PyraOS) is a separate project that cherry-picks some parts of LetuxOS.
To my knowledge, we would use the complete Letux kernel if it fullfilled everything we need (dbp needs aufs in the kernel, which isn't included).
I think we discussed that before and I suggested to use overlayfs which is maintained in mainline and is configured for Letux.
https://en.wikipedia.org/wiki/OverlayFS : "It was merged into the Linux kernel mainline in 2014, in kernel version 3.18.[4][5] It was improved in version 4.0, bringing improvements necessary for e.g. the overlay2 storage driver in Docker.[6] While most Live CD linux distributions used Aufs as of November 2016, Slackware used overlayfs for its live CD.[7]"
https://en.wikipedia.org/wiki/Aufs : "aufs was rejected for merging into mainline Linux. Its code was criticized for being "dense, unreadable, [and] uncommented".[3] Instead, OverlayFS was merged in the Linux kernel.[4][5] After several attempts to merge aufs into mainline kernel, the author has given up.[6]"
So the question for PyraOS is if you want to use something maintained upstream or have to merge in something with unclear future every now and then.
IMHO, the answer depends if aufs provides any feature that overlayfs can't provide or if it is just a matter of modifying some mount commands in dbp to make use of overlayfs.
So if possible and looking at the work-load and low number of developers available, I'd still recommend to switch to overlayfs for PyraOS. It is more future-proof.
But: there also seems to be an alternative for getting aufs:
https://en.wikipedia.org/wiki/Aufs : "Debian "stretch" does not include aufs anymore, but provides a package aufs-dkms, which auto-compiles the aufs kernel module using Dell's dkms." https://packages.debian.org/stretch/aufs-dkms
So it does not need to be merged directly in any kernel tree and it could be made a build/install-dependency of the dbp package (which is also non-standard).
For example the TILER did work up to 4.18.x but is broken since 4.19-rc1. There was some manual rebase conflict resolution involved, so it might be a bug introduced by that. Or it might be a new API mismatch.
Was it really working or simply not complaining when compiling?
Yes. I use it almost every day with Letux-4.18.8. With 4.19-rc it is only partially working (see http://lists.goldelico.com/pipermail/letux-kernel/2018-August/002497.html).
Because with the PyraOS, rotation worked fine with Kernel 4.15, but with 4.18, the framebuffer showed a black picture as soon as we enabled TILER rotation.
Hm. I wasn't aware of. Maybe such bugs should be reported somehow.
The bug I know with 4.19-rc# is that the image is rotated, but you see only a 32x32 (or 64x64?) pixel area of the framebuffer replicated all over the screen. With X11 it seems to be the last updated area (e.g. mouse pointer or clock digit jumping).
It looks like this
http://lists.goldelico.com/pipermail/letux-kernel/attachments/20180828/92434...
After reconsidering this picture, it came to my mind that I did a screenshot and not take a photo (the LCD image looks the same)!
So this means Idid read back the framebuffer. This is wrong (virtual address mapping?) and the TILER itself is still working.
This finding reduces the number of patches and code locations to look at. And I should compare with TILER patch set removed.
Making screen rotation work again is already on the top of my urgency list.
Without rotation, the framebuffer worked.
This might be a setup/config problem then. Needs more analysis and unfortunately I have no idea how PyraOS is trying to do the setup...
BR, Nikolaus
On 9/20/18 9:07 AM, H. Nikolaus Schaller wrote:
Hi all,
Am 20.09.2018 um 00:46 schrieb Michael Mrozek EvilDragon@openpandora.org:
On Mi, 2018-09-19 at 11:03 +0200, H. Nikolaus Schaller wrote:
Well, I'm a bit confused myself here, so maybe aTc can shed some light here.
Here's what I know:
The Pyra uses a Debian-Base OS with Pyra-specific addons (as packages).
The source for the packages can be found on https://dev.pyra-handheld.com
As far as I am aware, aTc uses the Letux kernel with a few patches and a different config... but I have no idea where these are available :/
Yes, I'd like to add the pyra_defconfig to the Letux kernel tree.
There isn't really a pyra_defconfig. It's just the Letux kernel and letux_lpae_defconfig with aufs enabled, and sometimes a few other things someone requested to be enabled for experimenting.
There are various other pyra kernel sources spread all over the internet, but all of them have been merged into letux by this stage.
I don't have all of them combined in a source repo somewhere, but all of the packaged kernels on packages.pyra-handheld.com also have the source debs on there.
There is also a linux-image GIT... but that seems outdated, so I don't think it's this he's using: https://dev.pyra-handheld.com/packages/linux-image-pyra
It is used, but it's just a meta package that depends on the latest kernel. Since 4.15 is the one that has the least amount of issues on my hardware, it's still set to that as the default.
There's also a U-Boot source, but I'm not sure this is exactly what aTc uses: https://dev.pyra-handheld.com/notaz/pyra-u-boot
That's the one. And that should just be the letux uboot with the distro/extlinux option enabled, so I get a nice boot menu, and an easier way to install and switch multiple kernels/boot options.
I think we discussed that before and I suggested to use overlayfs which is maintained in mainline and is configured for Letux.
IMHO, the answer depends if aufs provides any feature that overlayfs can't provide or if it is just a matter of modifying some mount commands
I think the problem with overlayfs was that it can't overlay on top of a fs that doesn't have the same features. And since it has to overlay ext/f2fs/squashfs on top of a fat formatted sd card, there are a lot of user/group/protection bits missing. aufs doesn't have that limitation.
Without rotation, the framebuffer worked.
This might be a setup/config problem then. Needs more analysis and unfortunately I have no idea how PyraOS is trying to do the setup...
It just sets the rotation through the kernel cmdline, and uses fbturbo as the xorg driver. fbturbo does fail on the later kernels sometimes, but i think that's related to the tiler issues. I pretty much assume the kernel gets everything in a working state, and doesn't require any additional scripts to fully initialize the hardware.
Hi,
Am 20.09.2018 um 11:54 schrieb aTc atc@k-n-p.org:
On 9/20/18 9:07 AM, H. Nikolaus Schaller wrote:
Hi all,
Am 20.09.2018 um 00:46 schrieb Michael Mrozek EvilDragon@openpandora.org:
On Mi, 2018-09-19 at 11:03 +0200, H. Nikolaus Schaller wrote:
Well, I'm a bit confused myself here, so maybe aTc can shed some light here.
Here's what I know:
The Pyra uses a Debian-Base OS with Pyra-specific addons (as packages).
The source for the packages can be found on https://dev.pyra-handheld.com
As far as I am aware, aTc uses the Letux kernel with a few patches and a different config... but I have no idea where these are available :/
Yes, I'd like to add the pyra_defconfig to the Letux kernel tree.
There isn't really a pyra_defconfig. It's just the Letux kernel and letux_lpae_defconfig with aufs enabled, and sometimes a few other things someone requested to be enabled for experimenting.
Ok, then we of course do not need a separate pyra_defconfig (which simplifies maintainer's task...).
There are various other pyra kernel sources spread all over the internet, but all of them have been merged into letux by this stage.
I don't have all of them combined in a source repo somewhere, but all of the packaged kernels on packages.pyra-handheld.com also have the source debs on there.
There is also a linux-image GIT... but that seems outdated, so I don't think it's this he's using: https://dev.pyra-handheld.com/packages/linux-image-pyra
It is used, but it's just a meta package that depends on the latest kernel. Since 4.15 is the one that has the least amount of issues on my hardware, it's still set to that as the default.
There's also a U-Boot source, but I'm not sure this is exactly what aTc uses: https://dev.pyra-handheld.com/notaz/pyra-u-boot
That's the one. And that should just be the letux uboot with the distro/extlinux option enabled, so I get a nice boot menu, and an easier way to install and switch multiple kernels/boot options.
I have collected most of the patches that are circleing around but not yet pushed because I was blocked by adding some hacks to try to identify the "reboot" issue. It is not yet solved, but analysed to a level where such hacks to u-boot are no longer needed. So I should start to clean up and push.
I think we discussed that before and I suggested to use overlayfs which is maintained in mainline and is configured for Letux.
IMHO, the answer depends if aufs provides any feature that overlayfs can't provide or if it is just a matter of modifying some mount commands
I think the problem with overlayfs was that it can't overlay on top of a fs that doesn't have the same features. And since it has to overlay ext/f2fs/squashfs on top of a fat formatted sd card, there are a lot of user/group/protection bits missing. aufs doesn't have that limitation.
Ok, I see. e have to check if overlayfs does support this now (it is quite a long time in the kernel now and others might have had the same requirements).
But a question: the FAT partition is for booting only and not used after the kernel is running. So where does the need for overlaying FAT file systems come from? Other cards with FAT format inserted into a second slot?
I have also studied a little:
https://www.kernel.org/doc/Documentation/filesystems/overlayfs.txt
There is no mention of such a limitation for FAT. It rather talks about directories (and not file systems).
And if I did understand correctly, doing a chown/chmod on an overlay on FAT it will make a copy of the file and then change attributes of the copy. So in overlay mode it looks as if FAT magically gets such attributes (inheriting some default from FAT).
Anyways I am not at all an expert on such details. I just want to make sure that we do not depend too much on out-of-tree code which means increased maintainance work for us.
Without rotation, the framebuffer worked.
This might be a setup/config problem then. Needs more analysis and unfortunately I have no idea how PyraOS is trying to do the setup...
It just sets the rotation through the kernel cmdline, and uses fbturbo as the xorg driver. fbturbo does fail on the later kernels sometimes, but i think that's related to the tiler issues. I pretty much assume the kernel gets everything in a working state, and doesn't require any additional scripts to fully initialize the hardware.
LetuxOS isn't doing it much differently - except that it does not have a fixed parameter in the cmdline, but does run this script with parameter "270" before launching X11.
#!/bin/sh # # control OMAP5 tiler rotation # following the how-to provided by atc@k-n-p.org #
case "$1" in 0 ) ROTATION=0;; 90 ) ROTATION=2;; 180 ) ROTATION=4;; 270 ) ROTATION=8;; * ) echo "usage: $0 0|90|180|270" 2>&1 exit 1;; esac
echo "$1 -> $ROTATION"
# no idea what this does and why it is needed... echo 0 >/sys/class/vtconsole/vtcon1/bind
# unload modules (fails if Xorg is already running) modprobe -r omapdrm modprobe -r drm_kms_helper # load with rotation parameter modprobe drm_kms_helper fbdev_rotation=$ROTATION modprobe omapdrm
# other strange stuff... # cat /dev/dri/card0 > /dev/null &
So maybe fbturbo vs. standard X11 server is the problem.
BTW: I think passing rotation to the drm_kms_helper could also be done in /etc/modprobe.d/drm_kms_helper.conf
Anyways, this TILER thing is something which needs more work. And upstreaming.
BR, Nikolaus
Nikolaus, from what I understand aufs is essentially only used in the community invented DBP system that is the successor to the PND system for the Pandora.
https://www.pyra-handheld.com/wiki/index.php?title=.dbp http://github.com/slaeshjag/dbp
On Thu, Sep 20, 2018 at 7:59 AM H. Nikolaus Schaller hns@goldelico.com wrote:
Hi,
Am 20.09.2018 um 11:54 schrieb aTc atc@k-n-p.org:
On 9/20/18 9:07 AM, H. Nikolaus Schaller wrote:
Hi all,
Am 20.09.2018 um 00:46 schrieb Michael Mrozek <
EvilDragon@openpandora.org>:
On Mi, 2018-09-19 at 11:03 +0200, H. Nikolaus Schaller wrote:
Well, I'm a bit confused myself here, so maybe aTc can shed some light here.
Here's what I know:
The Pyra uses a Debian-Base OS with Pyra-specific addons (as packages).
The source for the packages can be found on https://dev.pyra-handheld.com
As far as I am aware, aTc uses the Letux kernel with a few patches and a different config... but I have no idea where these are available :/
Yes, I'd like to add the pyra_defconfig to the Letux kernel tree.
There isn't really a pyra_defconfig. It's just the Letux kernel and
letux_lpae_defconfig with aufs enabled, and sometimes a few other things someone requested to be enabled for experimenting.
Ok, then we of course do not need a separate pyra_defconfig (which simplifies maintainer's task...).
There are various other pyra kernel sources spread all over the
internet, but all of them have been merged into letux by this stage.
I don't have all of them combined in a source repo somewhere, but all of
the packaged kernels on packages.pyra-handheld.com also have the source debs on there.
There is also a linux-image GIT... but that seems outdated, so I don't think it's this he's using: https://dev.pyra-handheld.com/packages/linux-image-pyra
It is used, but it's just a meta package that depends on the latest
kernel. Since 4.15 is the one that has the least amount of issues on my hardware, it's still set to that as the default.
There's also a U-Boot source, but I'm not sure this is exactly what aTc uses: https://dev.pyra-handheld.com/notaz/pyra-u-boot
That's the one. And that should just be the letux uboot with the distro/extlinux option
enabled, so I get a nice boot menu, and an easier way to install and switch multiple kernels/boot options.
I have collected most of the patches that are circleing around but not yet pushed because I was blocked by adding some hacks to try to identify the "reboot" issue. It is not yet solved, but analysed to a level where such hacks to u-boot are no longer needed. So I should start to clean up and push.
I think we discussed that before and I suggested to use overlayfs which is maintained in mainline and is configured for Letux.
IMHO, the answer depends if aufs provides any feature that overlayfs can't provide or if it is just a matter of modifying some mount commands
I think the problem with overlayfs was that it can't overlay on top of a
fs that doesn't have the same features. And since it has to overlay ext/f2fs/squashfs on top of a fat formatted sd card, there are a lot of user/group/protection bits missing. aufs doesn't have that limitation.
Ok, I see. e have to check if overlayfs does support this now (it is quite a long time in the kernel now and others might have had the same requirements).
But a question: the FAT partition is for booting only and not used after the kernel is running. So where does the need for overlaying FAT file systems come from? Other cards with FAT format inserted into a second slot?
I have also studied a little:
https://www.kernel.org/doc/Documentation/filesystems/overlayfs.txt
There is no mention of such a limitation for FAT. It rather talks about directories (and not file systems).
And if I did understand correctly, doing a chown/chmod on an overlay on FAT it will make a copy of the file and then change attributes of the copy. So in overlay mode it looks as if FAT magically gets such attributes (inheriting some default from FAT).
Anyways I am not at all an expert on such details. I just want to make sure that we do not depend too much on out-of-tree code which means increased maintainance work for us.
Without rotation, the framebuffer worked.
This might be a setup/config problem then. Needs more analysis and
unfortunately
I have no idea how PyraOS is trying to do the setup...
It just sets the rotation through the kernel cmdline, and uses fbturbo
as the xorg driver. fbturbo does fail on the later kernels sometimes, but i think that's related to the tiler issues.
I pretty much assume the kernel gets everything in a working state, and
doesn't require any additional scripts to fully initialize the hardware.
LetuxOS isn't doing it much differently - except that it does not have a fixed parameter in the cmdline, but does run this script with parameter "270" before launching X11.
#!/bin/sh # # control OMAP5 tiler rotation # following the how-to provided by atc@k-n-p.org #
case "$1" in 0 ) ROTATION=0;; 90 ) ROTATION=2;; 180 ) ROTATION=4;; 270 ) ROTATION=8;; * ) echo "usage: $0 0|90|180|270" 2>&1 exit 1;; esac
echo "$1 -> $ROTATION"
# no idea what this does and why it is needed... echo 0 >/sys/class/vtconsole/vtcon1/bind
# unload modules (fails if Xorg is already running) modprobe -r omapdrm modprobe -r drm_kms_helper # load with rotation parameter modprobe drm_kms_helper fbdev_rotation=$ROTATION modprobe omapdrm
# other strange stuff... # cat /dev/dri/card0 > /dev/null &
So maybe fbturbo vs. standard X11 server is the problem.
BTW: I think passing rotation to the drm_kms_helper could also be done in /etc/modprobe.d/drm_kms_helper.conf
Anyways, this TILER thing is something which needs more work. And upstreaming.
BR, Nikolaus
Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
Hi Roy,
Am 20.09.2018 um 14:15 schrieb Roy Gillotti gillottir@gmail.com:
Nikolaus, from what I understand aufs is essentially only used in the community invented DBP system that is the successor to the PND system for the Pandora.
https://www.pyra-handheld.com/wiki/index.php?title=.dbp https://www.pyra-handheld.com/wiki/index.php?title=.dbp http://github.com/slaeshjag/dbp http://github.com/slaeshjag/dbp
Yes, I am aware of this.
aufs is the low-level component of the DBP system which allows to merge files from a hot swapped SD card into the OS which itself is running from eMMC or other SD card.
What I don't know and question is if it is essential to use "aufs" or use "overlayfs" which seems that it can do exactly the same. Both have the same purpose, one is officially accepted by kernel.org. But they may have technical limitations.
So my suggestion would be: if overlayfs can do the same, then modify dbp to make use of it instead of requiring aufs. It would remove a depenceny for external code from the Pyra kernel.
BR, Nikolaus
On Thu, Sep 20, 2018 at 7:59 AM H. Nikolaus Schaller <hns@goldelico.com mailto:hns@goldelico.com> wrote: Hi,
Am 20.09.2018 um 11:54 schrieb aTc <atc@k-n-p.org mailto:atc@k-n-p.org>:
On 9/20/18 9:07 AM, H. Nikolaus Schaller wrote:
Hi all,
Am 20.09.2018 um 00:46 schrieb Michael Mrozek <EvilDragon@openpandora.org mailto:EvilDragon@openpandora.org>:
On Mi, 2018-09-19 at 11:03 +0200, H. Nikolaus Schaller wrote:
Well, I'm a bit confused myself here, so maybe aTc can shed some light here.
Here's what I know:
The Pyra uses a Debian-Base OS with Pyra-specific addons (as packages).
The source for the packages can be found on https://dev.pyra-handheld.com https://dev.pyra-handheld.com/
As far as I am aware, aTc uses the Letux kernel with a few patches and a different config... but I have no idea where these are available :/
Yes, I'd like to add the pyra_defconfig to the Letux kernel tree.
There isn't really a pyra_defconfig. It's just the Letux kernel and letux_lpae_defconfig with aufs enabled, and sometimes a few other things someone requested to be enabled for experimenting.
Ok, then we of course do not need a separate pyra_defconfig (which simplifies maintainer's task...).
There are various other pyra kernel sources spread all over the internet, but all of them have been merged into letux by this stage.
I don't have all of them combined in a source repo somewhere, but all of the packaged kernels on packages.pyra-handheld.com http://packages.pyra-handheld.com/ also have the source debs on there.
There is also a linux-image GIT... but that seems outdated, so I don't think it's this he's using: https://dev.pyra-handheld.com/packages/linux-image-pyra https://dev.pyra-handheld.com/packages/linux-image-pyra
It is used, but it's just a meta package that depends on the latest kernel. Since 4.15 is the one that has the least amount of issues on my hardware, it's still set to that as the default.
There's also a U-Boot source, but I'm not sure this is exactly what aTc uses: https://dev.pyra-handheld.com/notaz/pyra-u-boot https://dev.pyra-handheld.com/notaz/pyra-u-boot
That's the one. And that should just be the letux uboot with the distro/extlinux option enabled, so I get a nice boot menu, and an easier way to install and switch multiple kernels/boot options.
I have collected most of the patches that are circleing around but not yet pushed because I was blocked by adding some hacks to try to identify the "reboot" issue. It is not yet solved, but analysed to a level where such hacks to u-boot are no longer needed. So I should start to clean up and push.
I think we discussed that before and I suggested to use overlayfs which is maintained in mainline and is configured for Letux.
IMHO, the answer depends if aufs provides any feature that overlayfs can't provide or if it is just a matter of modifying some mount commands
I think the problem with overlayfs was that it can't overlay on top of a fs that doesn't have the same features. And since it has to overlay ext/f2fs/squashfs on top of a fat formatted sd card, there are a lot of user/group/protection bits missing. aufs doesn't have that limitation.
Ok, I see. e have to check if overlayfs does support this now (it is quite a long time in the kernel now and others might have had the same requirements).
But a question: the FAT partition is for booting only and not used after the kernel is running. So where does the need for overlaying FAT file systems come from? Other cards with FAT format inserted into a second slot?
I have also studied a little:
https://www.kernel.org/doc/Documentation/filesystems/overlayfs.txt https://www.kernel.org/doc/Documentation/filesystems/overlayfs.txt
There is no mention of such a limitation for FAT. It rather talks about directories (and not file systems).
And if I did understand correctly, doing a chown/chmod on an overlay on FAT it will make a copy of the file and then change attributes of the copy. So in overlay mode it looks as if FAT magically gets such attributes (inheriting some default from FAT).
Anyways I am not at all an expert on such details. I just want to make sure that we do not depend too much on out-of-tree code which means increased maintainance work for us.
Without rotation, the framebuffer worked.
This might be a setup/config problem then. Needs more analysis and unfortunately I have no idea how PyraOS is trying to do the setup...
It just sets the rotation through the kernel cmdline, and uses fbturbo as the xorg driver. fbturbo does fail on the later kernels sometimes, but i think that's related to the tiler issues. I pretty much assume the kernel gets everything in a working state, and doesn't require any additional scripts to fully initialize the hardware.
LetuxOS isn't doing it much differently - except that it does not have a fixed parameter in the cmdline, but does run this script with parameter "270" before launching X11.
#!/bin/sh # # control OMAP5 tiler rotation # following the how-to provided by atc@k-n-p.org mailto:atc@k-n-p.org #
case "$1" in 0 ) ROTATION=0;; 90 ) ROTATION=2;; 180 ) ROTATION=4;; 270 ) ROTATION=8;; * ) echo "usage: $0 0|90|180|270" 2>&1 exit 1;; esac
echo "$1 -> $ROTATION"
# no idea what this does and why it is needed... echo 0 >/sys/class/vtconsole/vtcon1/bind
# unload modules (fails if Xorg is already running) modprobe -r omapdrm modprobe -r drm_kms_helper # load with rotation parameter modprobe drm_kms_helper fbdev_rotation=$ROTATION modprobe omapdrm
# other strange stuff... # cat /dev/dri/card0 > /dev/null &
So maybe fbturbo vs. standard X11 server is the problem.
BTW: I think passing rotation to the drm_kms_helper could also be done in /etc/modprobe.d/drm_kms_helper.conf
Anyways, this TILER thing is something which needs more work. And upstreaming.
BR, Nikolaus
Kernel mailing list Kernel@pyra-handheld.com mailto:Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
Just a reminder, zmatt notified on irc that the shell script for the rotation has a bug, and for 0° it should be ROTATION=1 and not 0.
Sebastien.
Le jeu. 20 sept. 2018 à 14:27, H. Nikolaus Schaller hns@goldelico.com a écrit :
Hi Roy,
Am 20.09.2018 um 14:15 schrieb Roy Gillotti gillottir@gmail.com:
Nikolaus, from what I understand aufs is essentially only used in the community invented DBP system that is the successor to the PND system for the Pandora.
https://www.pyra-handheld.com/wiki/index.php?title=.dbp http://github.com/slaeshjag/dbp
Yes, I am aware of this.
aufs is the low-level component of the DBP system which allows to merge files from a hot swapped SD card into the OS which itself is running from eMMC or other SD card.
What I don't know and question is if it is essential to use "aufs" or use "overlayfs" which seems that it can do exactly the same. Both have the same purpose, one is officially accepted by kernel.org. But they may have technical limitations.
So my suggestion would be: if overlayfs can do the same, then modify dbp to make use of it instead of requiring aufs. It would remove a depenceny for external code from the Pyra kernel.
BR, Nikolaus
On Thu, Sep 20, 2018 at 7:59 AM H. Nikolaus Schaller hns@goldelico.com wrote:
Hi,
Am 20.09.2018 um 11:54 schrieb aTc atc@k-n-p.org:
On 9/20/18 9:07 AM, H. Nikolaus Schaller wrote:
Hi all,
Am 20.09.2018 um 00:46 schrieb Michael Mrozek <
EvilDragon@openpandora.org>:
On Mi, 2018-09-19 at 11:03 +0200, H. Nikolaus Schaller wrote:
Well, I'm a bit confused myself here, so maybe aTc can shed some light here.
Here's what I know:
The Pyra uses a Debian-Base OS with Pyra-specific addons (as
packages).
The source for the packages can be found on https://dev.pyra-handheld.com
As far as I am aware, aTc uses the Letux kernel with a few patches and a different config... but I have no idea where these are available :/
Yes, I'd like to add the pyra_defconfig to the Letux kernel tree.
There isn't really a pyra_defconfig. It's just the Letux kernel and
letux_lpae_defconfig with aufs enabled, and sometimes a few other things someone requested to be enabled for experimenting.
Ok, then we of course do not need a separate pyra_defconfig (which simplifies maintainer's task...).
There are various other pyra kernel sources spread all over the
internet, but all of them have been merged into letux by this stage.
I don't have all of them combined in a source repo somewhere, but all
of the packaged kernels on packages.pyra-handheld.com also have the source debs on there.
There is also a linux-image GIT... but that seems outdated, so I don't think it's this he's using: https://dev.pyra-handheld.com/packages/linux-image-pyra
It is used, but it's just a meta package that depends on the latest
kernel. Since 4.15 is the one that has the least amount of issues on my hardware, it's still set to that as the default.
There's also a U-Boot source, but I'm not sure this is exactly what
aTc
That's the one. And that should just be the letux uboot with the distro/extlinux option
enabled, so I get a nice boot menu, and an easier way to install and switch multiple kernels/boot options.
I have collected most of the patches that are circleing around but not yet pushed because I was blocked by adding some hacks to try to identify the "reboot" issue. It is not yet solved, but analysed to a level where such hacks to u-boot are no longer needed. So I should start to clean up and push.
I think we discussed that before and I suggested to use overlayfs which is maintained in mainline and is configured for Letux.
IMHO, the answer depends if aufs provides any feature that overlayfs can't provide or if it is just a matter of modifying some mount
commands
I think the problem with overlayfs was that it can't overlay on top of
a fs that doesn't have the same features. And since it has to overlay ext/f2fs/squashfs on top of a fat formatted sd card, there are a lot of user/group/protection bits missing. aufs doesn't have that limitation.
Ok, I see. e have to check if overlayfs does support this now (it is quite a long time in the kernel now and others might have had the same requirements).
But a question: the FAT partition is for booting only and not used after the kernel is running. So where does the need for overlaying FAT file systems come from? Other cards with FAT format inserted into a second slot?
I have also studied a little:
https://www.kernel.org/doc/Documentation/filesystems/overlayfs.txt
There is no mention of such a limitation for FAT. It rather talks about directories (and not file systems).
And if I did understand correctly, doing a chown/chmod on an overlay on FAT it will make a copy of the file and then change attributes of the copy. So in overlay mode it looks as if FAT magically gets such attributes (inheriting some default from FAT).
Anyways I am not at all an expert on such details. I just want to make sure that we do not depend too much on out-of-tree code which means increased maintainance work for us.
Without rotation, the framebuffer worked.
This might be a setup/config problem then. Needs more analysis and
unfortunately
I have no idea how PyraOS is trying to do the setup...
It just sets the rotation through the kernel cmdline, and uses fbturbo
as the xorg driver. fbturbo does fail on the later kernels sometimes, but i think that's related to the tiler issues.
I pretty much assume the kernel gets everything in a working state, and
doesn't require any additional scripts to fully initialize the hardware.
LetuxOS isn't doing it much differently - except that it does not have a fixed parameter in the cmdline, but does run this script with parameter "270" before launching X11.
#!/bin/sh # # control OMAP5 tiler rotation # following the how-to provided by atc@k-n-p.org #
case "$1" in 0 ) ROTATION=0;; 90 ) ROTATION=2;; 180 ) ROTATION=4;; 270 ) ROTATION=8;; * ) echo "usage: $0 0|90|180|270" 2>&1 exit 1;; esac
echo "$1 -> $ROTATION"
# no idea what this does and why it is needed... echo 0 >/sys/class/vtconsole/vtcon1/bind
# unload modules (fails if Xorg is already running) modprobe -r omapdrm modprobe -r drm_kms_helper # load with rotation parameter modprobe drm_kms_helper fbdev_rotation=$ROTATION modprobe omapdrm
# other strange stuff... # cat /dev/dri/card0 > /dev/null &
So maybe fbturbo vs. standard X11 server is the problem.
BTW: I think passing rotation to the drm_kms_helper could also be done in /etc/modprobe.d/drm_kms_helper.conf
Anyways, this TILER thing is something which needs more work. And upstreaming.
BR, Nikolaus
Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
Hi sebastien,
Am 20.09.2018 um 14:37 schrieb sebastien chevalier sebastien.chev@gmail.com:
Just a reminder, zmatt notified on irc that the shell script for the rotation has a bug, and for 0° it should be ROTATION=1 and not 0.
Good to know!
Well, IRC is not a bug tracker and does not replace submitting patches :)
It looks as if it has no negative/visible effect. I'll fix it anyways.
BR and thanks, Nikolaus
Sebastien.
Le jeu. 20 sept. 2018 à 14:27, H. Nikolaus Schaller <hns@goldelico.com mailto:hns@goldelico.com> a écrit : Hi Roy,
Am 20.09.2018 um 14:15 schrieb Roy Gillotti <gillottir@gmail.com mailto:gillottir@gmail.com>:
Nikolaus, from what I understand aufs is essentially only used in the community invented DBP system that is the successor to the PND system for the Pandora.
https://www.pyra-handheld.com/wiki/index.php?title=.dbp https://www.pyra-handheld.com/wiki/index.php?title=.dbp http://github.com/slaeshjag/dbp http://github.com/slaeshjag/dbp
Yes, I am aware of this.
aufs is the low-level component of the DBP system which allows to merge files from a hot swapped SD card into the OS which itself is running from eMMC or other SD card.
What I don't know and question is if it is essential to use "aufs" or use "overlayfs" which seems that it can do exactly the same. Both have the same purpose, one is officially accepted by kernel.org http://kernel.org/. But they may have technical limitations.
So my suggestion would be: if overlayfs can do the same, then modify dbp to make use of it instead of requiring aufs. It would remove a depenceny for external code from the Pyra kernel.
BR, Nikolaus
On Thu, Sep 20, 2018 at 7:59 AM H. Nikolaus Schaller <hns@goldelico.com mailto:hns@goldelico.com> wrote: Hi,
Am 20.09.2018 um 11:54 schrieb aTc <atc@k-n-p.org mailto:atc@k-n-p.org>:
On 9/20/18 9:07 AM, H. Nikolaus Schaller wrote:
Hi all,
Am 20.09.2018 um 00:46 schrieb Michael Mrozek <EvilDragon@openpandora.org mailto:EvilDragon@openpandora.org>:
On Mi, 2018-09-19 at 11:03 +0200, H. Nikolaus Schaller wrote:
Well, I'm a bit confused myself here, so maybe aTc can shed some light here.
Here's what I know:
The Pyra uses a Debian-Base OS with Pyra-specific addons (as packages).
The source for the packages can be found on https://dev.pyra-handheld.com https://dev.pyra-handheld.com/
As far as I am aware, aTc uses the Letux kernel with a few patches and a different config... but I have no idea where these are available :/
Yes, I'd like to add the pyra_defconfig to the Letux kernel tree.
There isn't really a pyra_defconfig. It's just the Letux kernel and letux_lpae_defconfig with aufs enabled, and sometimes a few other things someone requested to be enabled for experimenting.
Ok, then we of course do not need a separate pyra_defconfig (which simplifies maintainer's task...).
There are various other pyra kernel sources spread all over the internet, but all of them have been merged into letux by this stage.
I don't have all of them combined in a source repo somewhere, but all of the packaged kernels on packages.pyra-handheld.com http://packages.pyra-handheld.com/ also have the source debs on there.
There is also a linux-image GIT... but that seems outdated, so I don't think it's this he's using: https://dev.pyra-handheld.com/packages/linux-image-pyra https://dev.pyra-handheld.com/packages/linux-image-pyra
It is used, but it's just a meta package that depends on the latest kernel. Since 4.15 is the one that has the least amount of issues on my hardware, it's still set to that as the default.
There's also a U-Boot source, but I'm not sure this is exactly what aTc uses: https://dev.pyra-handheld.com/notaz/pyra-u-boot https://dev.pyra-handheld.com/notaz/pyra-u-boot
That's the one. And that should just be the letux uboot with the distro/extlinux option enabled, so I get a nice boot menu, and an easier way to install and switch multiple kernels/boot options.
I have collected most of the patches that are circleing around but not yet pushed because I was blocked by adding some hacks to try to identify the "reboot" issue. It is not yet solved, but analysed to a level where such hacks to u-boot are no longer needed. So I should start to clean up and push.
I think we discussed that before and I suggested to use overlayfs which is maintained in mainline and is configured for Letux.
IMHO, the answer depends if aufs provides any feature that overlayfs can't provide or if it is just a matter of modifying some mount commands
I think the problem with overlayfs was that it can't overlay on top of a fs that doesn't have the same features. And since it has to overlay ext/f2fs/squashfs on top of a fat formatted sd card, there are a lot of user/group/protection bits missing. aufs doesn't have that limitation.
Ok, I see. e have to check if overlayfs does support this now (it is quite a long time in the kernel now and others might have had the same requirements).
But a question: the FAT partition is for booting only and not used after the kernel is running. So where does the need for overlaying FAT file systems come from? Other cards with FAT format inserted into a second slot?
I have also studied a little:
https://www.kernel.org/doc/Documentation/filesystems/overlayfs.txt https://www.kernel.org/doc/Documentation/filesystems/overlayfs.txt
There is no mention of such a limitation for FAT. It rather talks about directories (and not file systems).
And if I did understand correctly, doing a chown/chmod on an overlay on FAT it will make a copy of the file and then change attributes of the copy. So in overlay mode it looks as if FAT magically gets such attributes (inheriting some default from FAT).
Anyways I am not at all an expert on such details. I just want to make sure that we do not depend too much on out-of-tree code which means increased maintainance work for us.
Without rotation, the framebuffer worked.
This might be a setup/config problem then. Needs more analysis and unfortunately I have no idea how PyraOS is trying to do the setup...
It just sets the rotation through the kernel cmdline, and uses fbturbo as the xorg driver. fbturbo does fail on the later kernels sometimes, but i think that's related to the tiler issues. I pretty much assume the kernel gets everything in a working state, and doesn't require any additional scripts to fully initialize the hardware.
LetuxOS isn't doing it much differently - except that it does not have a fixed parameter in the cmdline, but does run this script with parameter "270" before launching X11.
#!/bin/sh # # control OMAP5 tiler rotation # following the how-to provided by atc@k-n-p.org mailto:atc@k-n-p.org #
case "$1" in 0 ) ROTATION=0;; 90 ) ROTATION=2;; 180 ) ROTATION=4;; 270 ) ROTATION=8;; * ) echo "usage: $0 0|90|180|270" 2>&1 exit 1;; esac
echo "$1 -> $ROTATION"
# no idea what this does and why it is needed... echo 0 >/sys/class/vtconsole/vtcon1/bind
# unload modules (fails if Xorg is already running) modprobe -r omapdrm modprobe -r drm_kms_helper # load with rotation parameter modprobe drm_kms_helper fbdev_rotation=$ROTATION modprobe omapdrm
# other strange stuff... # cat /dev/dri/card0 > /dev/null &
So maybe fbturbo vs. standard X11 server is the problem.
BTW: I think passing rotation to the drm_kms_helper could also be done in /etc/modprobe.d/drm_kms_helper.conf
Anyways, this TILER thing is something which needs more work. And upstreaming.
BR, Nikolaus
Kernel mailing list Kernel@pyra-handheld.com mailto:Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
Kernel mailing list Kernel@pyra-handheld.com mailto:Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
Nikolaus,
Yeah, I know IRC is a bad ticket tracking media, but I just wanted to give proper credits...
The ROTATION=1 was needed to get 3D acceleration somehow working if I remember correctly.
Sebastien.
Le jeu. 20 sept. 2018 à 14:40, H. Nikolaus Schaller hns@goldelico.com a écrit :
Hi sebastien,
Am 20.09.2018 um 14:37 schrieb sebastien chevalier < sebastien.chev@gmail.com>:
Just a reminder, zmatt notified on irc that the shell script for the rotation has a bug, and for 0° it should be ROTATION=1 and not 0.
Good to know!
Well, IRC is not a bug tracker and does not replace submitting patches :)
It looks as if it has no negative/visible effect. I'll fix it anyways.
BR and thanks, Nikolaus
Sebastien.
Le jeu. 20 sept. 2018 à 14:27, H. Nikolaus Schaller hns@goldelico.com a écrit :
Hi Roy,
Am 20.09.2018 um 14:15 schrieb Roy Gillotti gillottir@gmail.com:
Nikolaus, from what I understand aufs is essentially only used in the community invented DBP system that is the successor to the PND system for the Pandora.
https://www.pyra-handheld.com/wiki/index.php?title=.dbp http://github.com/slaeshjag/dbp
Yes, I am aware of this.
aufs is the low-level component of the DBP system which allows to merge files from a hot swapped SD card into the OS which itself is running from eMMC or other SD card.
What I don't know and question is if it is essential to use "aufs" or use "overlayfs" which seems that it can do exactly the same. Both have the same purpose, one is officially accepted by kernel.org. But they may have technical limitations.
So my suggestion would be: if overlayfs can do the same, then modify dbp to make use of it instead of requiring aufs. It would remove a depenceny for external code from the Pyra kernel.
BR, Nikolaus
On Thu, Sep 20, 2018 at 7:59 AM H. Nikolaus Schaller hns@goldelico.com wrote:
Hi,
Am 20.09.2018 um 11:54 schrieb aTc atc@k-n-p.org:
On 9/20/18 9:07 AM, H. Nikolaus Schaller wrote:
Hi all,
Am 20.09.2018 um 00:46 schrieb Michael Mrozek <
EvilDragon@openpandora.org>:
On Mi, 2018-09-19 at 11:03 +0200, H. Nikolaus Schaller wrote:
Well, I'm a bit confused myself here, so maybe aTc can shed some
light
here.
Here's what I know:
The Pyra uses a Debian-Base OS with Pyra-specific addons (as
packages).
The source for the packages can be found on https://dev.pyra-handheld.com
As far as I am aware, aTc uses the Letux kernel with a few patches
and
a different config... but I have no idea where these are available :/
Yes, I'd like to add the pyra_defconfig to the Letux kernel tree.
There isn't really a pyra_defconfig. It's just the Letux kernel and
letux_lpae_defconfig with aufs enabled, and sometimes a few other things someone requested to be enabled for experimenting.
Ok, then we of course do not need a separate pyra_defconfig (which simplifies maintainer's task...).
There are various other pyra kernel sources spread all over the
internet, but all of them have been merged into letux by this stage.
I don't have all of them combined in a source repo somewhere, but all
of the packaged kernels on packages.pyra-handheld.com also have the source debs on there.
There is also a linux-image GIT... but that seems outdated, so I
don't
think it's this he's using: https://dev.pyra-handheld.com/packages/linux-image-pyra
It is used, but it's just a meta package that depends on the latest
kernel. Since 4.15 is the one that has the least amount of issues on my hardware, it's still set to that as the default.
There's also a U-Boot source, but I'm not sure this is exactly what
aTc
That's the one. And that should just be the letux uboot with the distro/extlinux
option enabled, so I get a nice boot menu, and an easier way to install and switch multiple kernels/boot options.
I have collected most of the patches that are circleing around but not yet pushed because I was blocked by adding some hacks to try to identify the "reboot" issue. It is not yet solved, but analysed to a level where such hacks to u-boot are no longer needed. So I should start to clean up and push.
I think we discussed that before and I suggested to use overlayfs which is maintained in mainline and is configured for Letux.
IMHO, the answer depends if aufs provides any feature that overlayfs can't provide or if it is just a matter of modifying some mount
commands
I think the problem with overlayfs was that it can't overlay on top of
a fs that doesn't have the same features. And since it has to overlay ext/f2fs/squashfs on top of a fat formatted sd card, there are a lot of user/group/protection bits missing. aufs doesn't have that limitation.
Ok, I see. e have to check if overlayfs does support this now (it is quite a long time in the kernel now and others might have had the same requirements).
But a question: the FAT partition is for booting only and not used after the kernel is running. So where does the need for overlaying FAT file systems come from? Other cards with FAT format inserted into a second slot?
I have also studied a little:
https://www.kernel.org/doc/Documentation/filesystems/overlayfs.txt
There is no mention of such a limitation for FAT. It rather talks about directories (and not file systems).
And if I did understand correctly, doing a chown/chmod on an overlay on FAT it will make a copy of the file and then change attributes of the copy. So in overlay mode it looks as if FAT magically gets such attributes (inheriting some default from FAT).
Anyways I am not at all an expert on such details. I just want to make sure that we do not depend too much on out-of-tree code which means increased maintainance work for us.
Without rotation, the framebuffer worked.
This might be a setup/config problem then. Needs more analysis and
unfortunately
I have no idea how PyraOS is trying to do the setup...
It just sets the rotation through the kernel cmdline, and uses fbturbo
as the xorg driver. fbturbo does fail on the later kernels sometimes, but i think that's related to the tiler issues.
I pretty much assume the kernel gets everything in a working state,
and doesn't require any additional scripts to fully initialize the hardware.
LetuxOS isn't doing it much differently - except that it does not have a fixed parameter in the cmdline, but does run this script with parameter "270" before launching X11.
#!/bin/sh # # control OMAP5 tiler rotation # following the how-to provided by atc@k-n-p.org #
case "$1" in 0 ) ROTATION=0;; 90 ) ROTATION=2;; 180 ) ROTATION=4;; 270 ) ROTATION=8;; * ) echo "usage: $0 0|90|180|270" 2>&1 exit 1;; esac
echo "$1 -> $ROTATION"
# no idea what this does and why it is needed... echo 0 >/sys/class/vtconsole/vtcon1/bind
# unload modules (fails if Xorg is already running) modprobe -r omapdrm modprobe -r drm_kms_helper # load with rotation parameter modprobe drm_kms_helper fbdev_rotation=$ROTATION modprobe omapdrm
# other strange stuff... # cat /dev/dri/card0 > /dev/null &
So maybe fbturbo vs. standard X11 server is the problem.
BTW: I think passing rotation to the drm_kms_helper could also be done in /etc/modprobe.d/drm_kms_helper.conf
Anyways, this TILER thing is something which needs more work. And upstreaming.
BR, Nikolaus
Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
Am 20.09.2018 um 14:48 schrieb sebastien chevalier sebastien.chev@gmail.com:
Nikolaus,
Yeah, I know IRC is a bad ticket tracking media, but I just wanted to give proper credits...
So your memory turned out the best ticker tracker :)
The ROTATION=1 was needed to get 3D acceleration somehow working if I remember correctly.
Ah, ok. Ihave never tried that so I wasn't aware of such effects.
BR and thanks, Nikolaus
Sebastien.
Le jeu. 20 sept. 2018 à 14:40, H. Nikolaus Schaller <hns@goldelico.com mailto:hns@goldelico.com> a écrit : Hi sebastien,
Am 20.09.2018 um 14:37 schrieb sebastien chevalier <sebastien.chev@gmail.com mailto:sebastien.chev@gmail.com>:
Just a reminder, zmatt notified on irc that the shell script for the rotation has a bug, and for 0° it should be ROTATION=1 and not 0.
Good to know!
Well, IRC is not a bug tracker and does not replace submitting patches :)
It looks as if it has no negative/visible effect. I'll fix it anyways.
BR and thanks, Nikolaus
Sebastien.
Le jeu. 20 sept. 2018 à 14:27, H. Nikolaus Schaller <hns@goldelico.com mailto:hns@goldelico.com> a écrit : Hi Roy,
Am 20.09.2018 um 14:15 schrieb Roy Gillotti <gillottir@gmail.com mailto:gillottir@gmail.com>:
Nikolaus, from what I understand aufs is essentially only used in the community invented DBP system that is the successor to the PND system for the Pandora.
https://www.pyra-handheld.com/wiki/index.php?title=.dbp https://www.pyra-handheld.com/wiki/index.php?title=.dbp http://github.com/slaeshjag/dbp http://github.com/slaeshjag/dbp
Yes, I am aware of this.
aufs is the low-level component of the DBP system which allows to merge files from a hot swapped SD card into the OS which itself is running from eMMC or other SD card.
What I don't know and question is if it is essential to use "aufs" or use "overlayfs" which seems that it can do exactly the same. Both have the same purpose, one is officially accepted by kernel.org http://kernel.org/. But they may have technical limitations.
So my suggestion would be: if overlayfs can do the same, then modify dbp to make use of it instead of requiring aufs. It would remove a depenceny for external code from the Pyra kernel.
BR, Nikolaus
On Thu, Sep 20, 2018 at 7:59 AM H. Nikolaus Schaller <hns@goldelico.com mailto:hns@goldelico.com> wrote: Hi,
Am 20.09.2018 um 11:54 schrieb aTc <atc@k-n-p.org mailto:atc@k-n-p.org>:
On 9/20/18 9:07 AM, H. Nikolaus Schaller wrote:
Hi all,
Am 20.09.2018 um 00:46 schrieb Michael Mrozek <EvilDragon@openpandora.org mailto:EvilDragon@openpandora.org>:
On Mi, 2018-09-19 at 11:03 +0200, H. Nikolaus Schaller wrote:
Well, I'm a bit confused myself here, so maybe aTc can shed some light here.
Here's what I know:
The Pyra uses a Debian-Base OS with Pyra-specific addons (as packages).
The source for the packages can be found on https://dev.pyra-handheld.com https://dev.pyra-handheld.com/
As far as I am aware, aTc uses the Letux kernel with a few patches and a different config... but I have no idea where these are available :/
Yes, I'd like to add the pyra_defconfig to the Letux kernel tree.
There isn't really a pyra_defconfig. It's just the Letux kernel and letux_lpae_defconfig with aufs enabled, and sometimes a few other things someone requested to be enabled for experimenting.
Ok, then we of course do not need a separate pyra_defconfig (which simplifies maintainer's task...).
There are various other pyra kernel sources spread all over the internet, but all of them have been merged into letux by this stage.
I don't have all of them combined in a source repo somewhere, but all of the packaged kernels on packages.pyra-handheld.com http://packages.pyra-handheld.com/ also have the source debs on there.
There is also a linux-image GIT... but that seems outdated, so I don't think it's this he's using: https://dev.pyra-handheld.com/packages/linux-image-pyra https://dev.pyra-handheld.com/packages/linux-image-pyra
It is used, but it's just a meta package that depends on the latest kernel. Since 4.15 is the one that has the least amount of issues on my hardware, it's still set to that as the default.
There's also a U-Boot source, but I'm not sure this is exactly what aTc uses: https://dev.pyra-handheld.com/notaz/pyra-u-boot https://dev.pyra-handheld.com/notaz/pyra-u-boot
That's the one. And that should just be the letux uboot with the distro/extlinux option enabled, so I get a nice boot menu, and an easier way to install and switch multiple kernels/boot options.
I have collected most of the patches that are circleing around but not yet pushed because I was blocked by adding some hacks to try to identify the "reboot" issue. It is not yet solved, but analysed to a level where such hacks to u-boot are no longer needed. So I should start to clean up and push.
I think we discussed that before and I suggested to use overlayfs which is maintained in mainline and is configured for Letux.
IMHO, the answer depends if aufs provides any feature that overlayfs can't provide or if it is just a matter of modifying some mount commands
I think the problem with overlayfs was that it can't overlay on top of a fs that doesn't have the same features. And since it has to overlay ext/f2fs/squashfs on top of a fat formatted sd card, there are a lot of user/group/protection bits missing. aufs doesn't have that limitation.
Ok, I see. e have to check if overlayfs does support this now (it is quite a long time in the kernel now and others might have had the same requirements).
But a question: the FAT partition is for booting only and not used after the kernel is running. So where does the need for overlaying FAT file systems come from? Other cards with FAT format inserted into a second slot?
I have also studied a little:
https://www.kernel.org/doc/Documentation/filesystems/overlayfs.txt https://www.kernel.org/doc/Documentation/filesystems/overlayfs.txt
There is no mention of such a limitation for FAT. It rather talks about directories (and not file systems).
And if I did understand correctly, doing a chown/chmod on an overlay on FAT it will make a copy of the file and then change attributes of the copy. So in overlay mode it looks as if FAT magically gets such attributes (inheriting some default from FAT).
Anyways I am not at all an expert on such details. I just want to make sure that we do not depend too much on out-of-tree code which means increased maintainance work for us.
Without rotation, the framebuffer worked.
This might be a setup/config problem then. Needs more analysis and unfortunately I have no idea how PyraOS is trying to do the setup...
It just sets the rotation through the kernel cmdline, and uses fbturbo as the xorg driver. fbturbo does fail on the later kernels sometimes, but i think that's related to the tiler issues. I pretty much assume the kernel gets everything in a working state, and doesn't require any additional scripts to fully initialize the hardware.
LetuxOS isn't doing it much differently - except that it does not have a fixed parameter in the cmdline, but does run this script with parameter "270" before launching X11.
#!/bin/sh # # control OMAP5 tiler rotation # following the how-to provided by atc@k-n-p.org mailto:atc@k-n-p.org #
case "$1" in 0 ) ROTATION=0;; 90 ) ROTATION=2;; 180 ) ROTATION=4;; 270 ) ROTATION=8;; * ) echo "usage: $0 0|90|180|270" 2>&1 exit 1;; esac
echo "$1 -> $ROTATION"
# no idea what this does and why it is needed... echo 0 >/sys/class/vtconsole/vtcon1/bind
# unload modules (fails if Xorg is already running) modprobe -r omapdrm modprobe -r drm_kms_helper # load with rotation parameter modprobe drm_kms_helper fbdev_rotation=$ROTATION modprobe omapdrm
# other strange stuff... # cat /dev/dri/card0 > /dev/null &
So maybe fbturbo vs. standard X11 server is the problem.
BTW: I think passing rotation to the drm_kms_helper could also be done in /etc/modprobe.d/drm_kms_helper.conf
Anyways, this TILER thing is something which needs more work. And upstreaming.
BR, Nikolaus
Kernel mailing list Kernel@pyra-handheld.com mailto:Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
Kernel mailing list Kernel@pyra-handheld.com mailto:Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
Hi,
On Tue, 18 Sep 2018 08:30:58 +0200 H. Nikolaus Schaller hns@goldelico.com wrote:
Hi all, I have finally updated our kernel trees to
letux-4.14.70 letux-4.18.8 letux-4.19-rc4
and as usual there are binaries and sources at the known locations.
Regarding 4.19-rc4 we have quite some construction sites, unfortunately with some regressions.
Here is the list of (significantly) broken things that I am aware of:
Pyra:
- OMAP5 TILER is no longer scanning through the frame buffer and appears to fetch from a fixed address
- "reboot" hangs if timer8 is in use
- bq2429x charger driver is far from being perfect (sometimes does not detect USB unplug/replug and charging does not start)
- AESS does not load firmware and even without, audio is broken
- PVR/SGX integration is missing
- sd/eMMC switch driver is missing
GTA04:
- camera driver is still not stable and incomplete
- PVR/SGX integration is incomplete
suspend works catastrophically at least on GTA04A5, totally unreliably. Do not know yet why.
Regards, Andreas
Hi Andreas,
Am 18.09.2018 um 21:34 schrieb Andreas Kemnade andreas@kemnade.info:
Hi,
On Tue, 18 Sep 2018 08:30:58 +0200 H. Nikolaus Schaller hns@goldelico.com wrote:
Hi all, I have finally updated our kernel trees to
letux-4.14.70 letux-4.18.8 letux-4.19-rc4
and as usual there are binaries and sources at the known locations.
Regarding 4.19-rc4 we have quite some construction sites, unfortunately with some regressions.
Here is the list of (significantly) broken things that I am aware of:
Pyra:
- OMAP5 TILER is no longer scanning through the frame buffer and appears to fetch from a fixed address
- "reboot" hangs if timer8 is in use
- bq2429x charger driver is far from being perfect (sometimes does not detect USB unplug/replug and charging does not start)
- AESS does not load firmware and even without, audio is broken
- PVR/SGX integration is missing
- sd/eMMC switch driver is missing
GTA04:
- camera driver is still not stable and incomplete
- PVR/SGX integration is incomplete
suspend works catastrophically at least on GTA04A5, totally unreliably. Do not know yet why.
Well, I might have mixed up something during manually fixing rebase conflicts...
Can you be a little more specific?
- is it not going to suspend? - does it not wake up again? - does it suspend but suspend power is too high?
BR, Nikolaus
On Wed, 19 Sep 2018 11:18:18 +0200 "H. Nikolaus Schaller" hns@goldelico.com wrote:
Hi Andreas,
Am 18.09.2018 um 21:34 schrieb Andreas Kemnade andreas@kemnade.info:
Hi,
On Tue, 18 Sep 2018 08:30:58 +0200 H. Nikolaus Schaller hns@goldelico.com wrote:
Hi all, I have finally updated our kernel trees to
letux-4.14.70 letux-4.18.8 letux-4.19-rc4
and as usual there are binaries and sources at the known locations.
Regarding 4.19-rc4 we have quite some construction sites, unfortunately with some regressions.
Here is the list of (significantly) broken things that I am aware of:
Pyra:
- OMAP5 TILER is no longer scanning through the frame buffer and appears to fetch from a fixed address
- "reboot" hangs if timer8 is in use
- bq2429x charger driver is far from being perfect (sometimes does not detect USB unplug/replug and charging does not start)
- AESS does not load firmware and even without, audio is broken
- PVR/SGX integration is missing
- sd/eMMC switch driver is missing
GTA04:
- camera driver is still not stable and incomplete
- PVR/SGX integration is incomplete
suspend works catastrophically at least on GTA04A5, totally unreliably. Do not know yet why.
Well, I might have mixed up something during manually fixing rebase conflicts...
Can you be a little more specific?
Well, I am still collecting and verifying (double checking things I have done). What I have seen: - 10mA too much power consumption if no modules loaded
- is it not going to suspend?
per and core power domains do not enter suspend state noirq suspend failed
on letux3704 that happens after loading camera modules, but also after other things I have not figured out. Running udev is enough. musb + phy + charging stuff considered not gulthy at first glance.
- does it not wake up again?
that also happened (or did it crash?)
- does it suspend but suspend power is too high?
not measured yet
will give more structured input soon.
Regards, Andreas
Hi Nikolaus,
On Wed, 19 Sep 2018 12:57:34 +0200 Andreas Kemnade andreas@kemnade.info wrote:
On Wed, 19 Sep 2018 11:18:18 +0200 "H. Nikolaus Schaller" hns@goldelico.com wrote:
Hi Andreas,
Am 18.09.2018 um 21:34 schrieb Andreas Kemnade andreas@kemnade.info:
Hi,
On Tue, 18 Sep 2018 08:30:58 +0200 H. Nikolaus Schaller hns@goldelico.com wrote:
Hi all, I have finally updated our kernel trees to
letux-4.14.70 letux-4.18.8 letux-4.19-rc4
and as usual there are binaries and sources at the known locations.
Regarding 4.19-rc4 we have quite some construction sites, unfortunately with some regressions.
Here is the list of (significantly) broken things that I am aware of:
Pyra:
- OMAP5 TILER is no longer scanning through the frame buffer and appears to fetch from a fixed address
- "reboot" hangs if timer8 is in use
- bq2429x charger driver is far from being perfect (sometimes does not detect USB unplug/replug and charging does not start)
- AESS does not load firmware and even without, audio is broken
- PVR/SGX integration is missing
- sd/eMMC switch driver is missing
GTA04:
- camera driver is still not stable and incomplete
- PVR/SGX integration is incomplete
suspend works catastrophically at least on GTA04A5, totally unreliably. Do not know yet why.
Well, I might have mixed up something during manually fixing rebase conflicts...
Can you be a little more specific?
Well, I am still collecting and verifying (double checking things I have done). What I have seen:
- 10mA too much power consumption if no modules loaded
- is it not going to suspend?
per and core power domains do not enter suspend state noirq suspend failed
on letux3704 that happens after loading camera modules, but also after other things I have not figured out. Running udev is enough. musb + phy + charging stuff considered not gulthy at first glance.
ok, checked more cleanly. Suspend on letux3704 seems not to be problematic, if omap3_isp is blacklisted, so maybe something there has to learn to clean up on probe failure. So either omap3_isp or the ov9650 module. GTA04A5 is a bit different story. Suspend problems there seems to be present starting at 4.19-rc1 even on mainline. But I will double-check that. At that evening I had just the idea to produce a quick v2 of my phy patch where Dmitry had some objections, so I was just searching for a good base to develop and test a v2.
Well, worst case will be an automated git bisect run next night. I have now a nice sdcard to jst-xh adapter "battery". So all what is additionally needed is one script which returns 0 if kernel is ok, 125 if it cannot be tested, something else on failure. And then I can do a git bisect run script.sh
Regards, Andreas
Hi,
On Tue, 18 Sep 2018 08:30:58 +0200 H. Nikolaus Schaller hns@goldelico.com wrote:
Hi all, I have finally updated our kernel trees to
letux-4.14.70 letux-4.18.8 letux-4.19-rc4
and as usual there are binaries and sources at the known locations.
Regarding 4.19-rc4 we have quite some construction sites, unfortunately with some regressions.
Here is the list of (significantly) broken things that I am aware of:
Pyra:
- OMAP5 TILER is no longer scanning through the frame buffer and appears to fetch from a fixed address
- "reboot" hangs if timer8 is in use
- bq2429x charger driver is far from being perfect (sometimes does not detect USB unplug/replug and charging does not start)
- AESS does not load firmware and even without, audio is broken
- PVR/SGX integration is missing
- sd/eMMC switch driver is missing
GTA04:
- camera driver is still not stable and incomplete
- PVR/SGX integration is incomplete
Another thing on letux3704: hdq woes: rmmod omap_hdq ; modprobe omap_hdq causes a lot of mess[1]:
enabling serial runtime auto-suspend confuses omap_hdq. I do not get values for current_now then. Background: Probably serial devices were the last user of many things in the soc (I did not load many modules), so re-requesting them by e.g. omap_hdq has to be done properly. Maybe that is the reason. I have not checked those things earlier, but there were some changes there, so I experimented a bit.
Others:
- Pandora WLAN is broken
- Pandora Audio is missing
- problems with generic-adc-battery (unreliable readings, % report less precise than it could be)
- Udoo neo: no HDMI driver
So all this needs help and support from our community.
BR, Nikolaus
http://projects.goldelico.com/p/gta04-kernel/ Letux-kernel mailing list Letux-kernel@openphoenux.org http://lists.goldelico.com/mailman/listinfo.cgi/letux-kernel
[1]: [ 444.268707] Hardware name: Generic OMAP36xx (Flattened Device Tree) [ 444.275329] [<c0110ddc>] (unwind_backtrace) from [<c010c2e8>] (show_stack+0x10/0x14) [ 444.283447] [<c010c2e8>] (show_stack) from [<c07909ac>] (dump_stack+0x7c/0x98) [ 444.291015] [<c07909ac>] (dump_stack) from [<c02ca6c0>] (sysfs_warn_dup+0x50/0x68) [ 444.298950] [<c02ca6c0>] (sysfs_warn_dup) from [<c02caa0c>] (sysfs_do_create_link_sd+0x90/0xac) [ 444.308044] [<c02caa0c>] (sysfs_do_create_link_sd) from [<c04fe504>] (bus_add_device+0x54/0xcc) [ 444.317138] [<c04fe504>] (bus_add_device) from [<c04fc820>] (device_add+0x390/0x570) [ 444.325256] [<c04fc820>] (device_add) from [<c061574c>] (w1_attach_slave_device+0x218/0x408) [ 444.334106] [<c061574c>] (w1_attach_slave_device) from [<c0615a98>] (w1_slave_found+0xb4/0xc4) [ 444.343109] [<c0615a98>] (w1_slave_found) from [<bf0d30a0>] (omap_w1_search_bus+0x54/0x78 [omap_hdq]) [ 444.352783] [<bf0d30a0>] (omap_w1_search_bus [omap_hdq]) from [<c0616264>] (w1_search_process_cb+0x4c/0xfc) [ 444.362976] [<c0616264>] (w1_search_process_cb) from [<c06163e4>] (w1_process+0x6c/0x118) [ 444.371520] [<c06163e4>] (w1_process) from [<c014f954>] (kthread+0x130/0x148) [ 444.378967] [<c014f954>] (kthread) from [<c01010e8>] (ret_from_fork+0x14/0x2c) [ 444.386535] Exception stack(0xdbd25fb0 to 0xdbd25ff8) [ 444.391815] 5fa0: 00000000 00000000 00000000 00000000 [ 444.400329] 5fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 444.408905] 5fe0: 00000000 00000000 00000000 00000000 00000013 00000000 [ 444.416198] w1_slave_driver 01-000000000000: Device registration [01-000000000000] failed. err=-17 [ 444.425720] w1_master_driver w1_bus_master2: w1_attach_slave_device: Attaching 01-000000000000 failed. [ 451.681915] Unable to handle kernel paging request at virtual address bf01d04c [ 451.689605] pgd = 6517225a [ 451.692687] [bf01d04c] *pgd=9bcdb811, *pte=00000000, *ppte=00000000 [ 451.699371] Internal error: Oops: 80000007 [#1] PREEMPT SMP ARM [ 451.705657] Modules linked in: omap_hdq usb_f_ecm omap2430 g_ether usb_f_rndis u_ether libcomposite configfs twl4030_charger industrialio phy_twl4030_usb musb_hdrc bq27xxx_battery_hdq bq27xxx_battery overlay [last unloaded: omap_hdq] [ 451.727691] CPU: 0 PID: 1063 Comm: w1_bus_master1 Not tainted 4.19.0-rc4-letux+ #34 [ 451.735809] Hardware name: Generic OMAP36xx (Flattened Device Tree) [ 451.742431] PC is at 0xbf01d04c [ 451.745819] LR is at w1_search_process_cb+0x4c/0xfc [ 451.750976] pc : [<bf01d04c>] lr : [<c0616264>] psr: a0000153 [ 451.757629] sp : dbcb1f48 ip : bf01d04c fp : ddb5b69c [ 451.763153] r10: dda80440 r9 : c06159e4 r8 : dda80440 [ 451.768676] r7 : 000000f0 r6 : dda8042c r5 : dda80400 r4 : dda8041c [ 451.775604] r3 : c06159e4 r2 : 000000f0 r1 : dda80400 r0 : dbc8e090 [ 451.782501] Flags: NzCv IRQs on FIQs off Mode SVC_32 ISA ARM Segment none [ 451.790161] Control: 10c5387d Table: 9bcac019 DAC: 00000051 [ 451.796234] Process w1_bus_master1 (pid: 1063, stack limit = 0x5a1bf9bc) [ 451.803344] Stack: (0xdbcb1f48 to 0xdbcb2000) [ 451.807983] 1f40: dda80400 00000000 dbcb0000 dda80490 000003e8 c06159e4 [ 451.816650] 1f60: ddc2dc34 c06163e4 ddb5b680 ddb5b700 dbcb0000 dda80400 c0616378 00000000 [ 451.825347] 1f80: ddc2dc34 c014f954 00000000 ddb5b700 c014f824 00000000 00000000 00000000 [ 451.834014] 1fa0: 00000000 00000000 00000000 c01010e8 00000000 00000000 00000000 00000000 [ 451.842681] 1fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 451.851348] 1fe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000 [ 451.860046] [<c0616264>] (w1_search_process_cb) from [<c06163e4>] (w1_process+0x6c/0x118) [ 451.868713] [<c06163e4>] (w1_process) from [<c014f954>] (kthread+0x130/0x148) [ 451.876312] [<c014f954>] (kthread) from [<c01010e8>] (ret_from_fork+0x14/0x2c) [ 451.883941] Exception stack(0xdbcb1fb0 to 0xdbcb1ff8) [ 451.889312] 1fa0: 00000000 00000000 00000000 00000000 [ 451.897979] 1fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 451.906616] 1fe0: 00000000 00000000 00000000 00000000 00000013 00000000 [ 451.913635] Code: bad PC value [ 451.916992] ---[ end trace 0c53a422b15a25b1 ]--- [ 454.881958] w1_master_driver w1_bus_master2: Attaching one wire slave 01.000000000000 crc 3d
Regards, Andreas
Hi,
On Tue, 18 Sep 2018 08:30:58 +0200 H. Nikolaus Schaller hns@goldelico.com wrote:
Hi all, I have finally updated our kernel trees to
letux-4.14.70 letux-4.18.8 letux-4.19-rc4
and as usual there are binaries and sources at the known locations.
Regarding 4.19-rc4 we have quite some construction sites, unfortunately with some regressions.
Here is the list of (significantly) broken things that I am aware of:
Pyra:
- OMAP5 TILER is no longer scanning through the frame buffer and appears to fetch from a fixed address
- "reboot" hangs if timer8 is in use
- bq2429x charger driver is far from being perfect (sometimes does not detect USB unplug/replug and charging does not start)
- AESS does not load firmware and even without, audio is broken
- PVR/SGX integration is missing
- sd/eMMC switch driver is missing
GTA04:
- camera driver is still not stable and incomplete
- PVR/SGX integration is incomplete
ok, no modem today... [ 2000.608673] wwan_on_off_set_power:on = 1 [ 2000.612792] wwan_on_off_is_powered_on: USB phy event 0 [ 2000.620391] wwan_on_off_is_powered_on: in-off invalid [ 2000.626434] wwan_on_off_is_powered_on: return 'true' [ 2000.631774] wwan_on_off_set_power: state 1 [ 2000.636596] wwan_on_off_set_power: done [ 2012.081024] wwan_on_off_rfkill_set_block: blocked: 1 [ 2012.087127] wwan_on_off_set_power:on = 0 [ 2012.091308] wwan_on_off_is_powered_on: USB phy event 0 [ 2012.100006] wwan_on_off_is_powered_on: in-off invalid [ 2012.105957] wwan_on_off_is_powered_on: return 'true' [ 2012.111297] wwan_on_off_set_power: state 1 [ 2012.116119] wwan_on_off_set_power: send impulse [ 2012.854522] wwan_on_off_is_powered_on: USB phy event 0 [ 2012.863067] wwan_on_off_is_powered_on: in-off invalid [ 2012.869476] wwan_on_off_is_powered_on: return 'true' [ 2012.875274] wwan_on_off_set_power: failed to change modem state [ 2012.881591] wwan_on_off_set_power: done [ 2017.281188] wwan_on_off_rfkill_set_block: blocked: 0
Regards, Andreas
Hi,
Am 22.09.2018 um 19:17 schrieb Andreas Kemnade andreas@kemnade.info:
Hi,
On Tue, 18 Sep 2018 08:30:58 +0200 H. Nikolaus Schaller hns@goldelico.com wrote:
Hi all, I have finally updated our kernel trees to
letux-4.14.70 letux-4.18.8 letux-4.19-rc4
and as usual there are binaries and sources at the known locations.
Regarding 4.19-rc4 we have quite some construction sites, unfortunately with some regressions.
Here is the list of (significantly) broken things that I am aware of:
Pyra:
- OMAP5 TILER is no longer scanning through the frame buffer and appears to fetch from a fixed address
- "reboot" hangs if timer8 is in use
- bq2429x charger driver is far from being perfect (sometimes does not detect USB unplug/replug and charging does not start)
- AESS does not load firmware and even without, audio is broken
- PVR/SGX integration is missing
- sd/eMMC switch driver is missing
GTA04:
- camera driver is still not stable and incomplete
- PVR/SGX integration is incomplete
ok, no modem today... [ 2000.608673] wwan_on_off_set_power:on = 1 [ 2000.612792] wwan_on_off_is_powered_on: USB phy event 0 [ 2000.620391] wwan_on_off_is_powered_on: in-off invalid [ 2000.626434] wwan_on_off_is_powered_on: return 'true' [ 2000.631774] wwan_on_off_set_power: state 1 [ 2000.636596] wwan_on_off_set_power: done [ 2012.081024] wwan_on_off_rfkill_set_block: blocked: 1 [ 2012.087127] wwan_on_off_set_power:on = 0 [ 2012.091308] wwan_on_off_is_powered_on: USB phy event 0 [ 2012.100006] wwan_on_off_is_powered_on: in-off invalid [ 2012.105957] wwan_on_off_is_powered_on: return 'true' [ 2012.111297] wwan_on_off_set_power: state 1 [ 2012.116119] wwan_on_off_set_power: send impulse [ 2012.854522] wwan_on_off_is_powered_on: USB phy event 0 [ 2012.863067] wwan_on_off_is_powered_on: in-off invalid [ 2012.869476] wwan_on_off_is_powered_on: return 'true' [ 2012.875274] wwan_on_off_set_power: failed to change modem state [ 2012.881591] wwan_on_off_set_power: done [ 2017.281188] wwan_on_off_rfkill_set_block: blocked: 0
There should already be a patch to fix that:
http://git.goldelico.com/?p=letux-kernel.git;a=commit;h=64ef5738ac669f964581...
The "in-off invalid" is a symptom that it is still missing in the merged tree.
I have also merged your other patches. So we just have to wait that Linus^H^H^H^H^HGreg is publishing v4.19-rc5.
BR and thanks, Nikolaus
-
Andreas Kemnade -
aTc -
H. Nikolaus Schaller -
Michael Mrozek -
N. Jackson -
Roy Gillotti -
sebastien chevalier