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
>>> 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

_______________________________________________
Kernel mailing list
Kernel@pyra-handheld.com
http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel