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