[Letux-kernel] Letux OS: Kernel 4.19-rc4

H. Nikolaus Schaller hns at goldelico.com
Thu Sep 20 09:07:19 CEST 2018


Hi all,

> Am 20.09.2018 um 00:46 schrieb Michael Mrozek <EvilDragon at 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/924342bb/attachment-0001.png

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




More information about the Letux-kernel mailing list