<aceridus>
jenneron[m]: Very nice! I will give these images a try hopefully in the next day or so. Any chance you can add an LXDE image to the list that gets built?
<jenneron[m]>
aceridus: we don't support lxde
<jenneron[m]>
use console image and install it manually
<jenneron[m]>
if you want to install on jerry, you should wait a week or 2, so we will get rid of need in u-boot
<jenneron[m]>
and installation will be much easier
<aceridus>
Sure. Is LXDE not maintained well anymore?
<jenneron[m]>
I don't know
<jenneron[m]>
not maintained in pmOS at all, but we use alpine repos
<jenneron[m]>
if alpine maintains it, then you can install it
<aceridus>
Are you saying to are getting rid of u-boot entirely for jerry devices or something in u-boot?
<aceridus>
you are*
<jenneron[m]>
for Jerry we currently require users to install u-boot manually
<jenneron[m]>
jerry*
<jenneron[m]>
we used to do this because depthcharge on it doesn't support on initramfs
<jenneron[m]>
doesn't support initramfs*
<aceridus>
Ahh, gotcha. Is there an advantage to using u-boot over only .kimg like Arch is doing? Or are you just aiming to use u-boot on everything for consistency?
<jenneron[m]>
(jenneron shouldn't type on a phone)
<jenneron[m]>
the advantage is initramfs support
<jenneron[m]>
because depthcharge on veyron devices doesn't support it
<jenneron[m]>
there is a way to workaround it now, i work on integration it in pmOS, so users won't have to install u-boot anymore
<aceridus>
Seems odd, is that a quirk of veyron in particular?
<jenneron[m]>
of all armv7 chromebooks
<aceridus>
Ok, that seems like an even stranger choice, wonder why Google thought that made sense...
<jenneron[m]>
because chrome os doesn't use initramfs
<jenneron[m]>
arch doesn't use initramfs too
<jenneron[m]>
pmOS does
<aceridus>
I know initramfs isn't require from all my years working with Linux, I just figured when they added the dev mode usb boot they would have though "hey, we might need to support initramfs cause many distributions use one"
<jenneron[m]>
they at least started to care about it on aarch64 devices
<jenneron[m]>
but actually they didn't have to
<aceridus>
Oh well. Is there a quick explanation of the workaround you are using?
<jenneron[m]>
initramfs indeed is not mandatory, but it allows us to properly mount partition, to use encrypted rootfs, to show splashscreen, etc
<aceridus>
Neat, I learned a little bit more about a couple dtb properties I was vaguely aware of. So, the FIT image contains the kernel and ramdisk and gets written to the 'Kernel' partition?
<jenneron[m]>
yes
<jenneron[m]>
<aceridus> "Sure. Is LXDE not maintained..." <- btw I strongly recommend wayland
<jenneron[m]>
in xorg I've got 3+ times less opengl performance
<jenneron[m]>
on veyron-speedy
<aceridus>
So, I guess depthcharge supports loading various image formats from the Kernel partition? FIT is one, but the .kpart image that Arch generates appears to be the kernel only and not a FIT image?
<jenneron[m]>
.kpart is GIT image in depthcharge format
<jenneron[m]>
arch just generates a FIT image without initramfs
<jenneron[m]>
FIT*
<hexdump0815>
jenneron[m]: congratulations to the images - will hopefully have some time between xmas and ny to test them for the ones i have hardware for
<jenneron[m]>
hexdump0815: better use pmbootstrap, because it is impossible to test FDE with these images
<hexdump0815>
this veyron initrd fix is very nice and clever :)
<hexdump0815>
jenneron[m]: you are right - using pmbootstrap is nearly as easy - will try this way then
<aceridus>
That is a big performance bump on Wayland. I really prefer Openbox either by itself or with LXDE, but it doesn't look clear to me if there is a good Wayland option for that. I found this: https://github.com/wizbright/waybox, not sure of the completeness or maturity level though.
<jenneron[m]>
these images are hopefully a temporary thing, next step is images with graphical on-device installer allowing to install with FDE
<hexdump0815>
jenneron[m]: ah - aneesh also tried my images - nice that he updated the wiki page which i still did not do
<aceridus>
What is FDE?
<jenneron[m]>
hexdump0815: btw which veyron devices do you have?
<jenneron[m]>
aceridus: full disk encryption
<hexdump0815>
jenneron[m]: i have a jaq (medion s2013), a mighty (medion s2015) and a minnie (asus c100)
<jenneron[m]>
nice
<jenneron[m]>
i'm going to add jaq and mighty soon
<aceridus>
jenneron[m]: Thanks, I'll take a look. It looks like I can pull over my Openbox .xml configs too without much issue
<jenneron[m]>
already added them to wiki, but not to pmaports yet
<hexdump0815>
ok - will test them then as well ... i think they are white label chromebooks, so there are more chromebooks with different names with those boards as well
<hexdump0815>
i plan to slowly go through all the chromebooks i'm trying to support to build new images based on the v6.1 kernel and when i test those new images i want to test the corresponding pmos install as well then
<jenneron[m]>
yeah there are many clones
<hexdump0815>
it will just take some time until i'm through them but step by step i should get forward ... currently i'm not having much energy to do much requiring effort on a computer after work
<jenneron[m]>
for now i just duplicated device pages for all the clones and made a redirect to one page
<jenneron[m]>
i see
<jenneron[m]>
i'm not in hurry, i want to have as many tested devices as possible until next release, but it will be in ~6 months
<hexdump0815>
that should work fine as in my experience the differences between the different systems of a family are usually quite small - often only audio and maybe display and touchpad/touchscreen
<jenneron[m]>
and if there are any issues, i want them fixed until then
<jenneron[m]>
hexdump0815: audio it's more about mt8183 devices
<jenneron[m]>
there are different dtbs for it
<hexdump0815>
yes - the older ones usually just have one audio setup - mt8183 seems to have dozens of different audio codecs in place - it looks like even different ones for different revisions of the same board :)
<jenneron[m]>
indeed
<jenneron[m]>
and annoying that we have to load modules manually
<hexdump0815>
i guess supply chain issues maybe, but i guess the design of the kukui devices should have been finished before corona, so maybe not
<jenneron[m]>
i have a vision how to fix loading modules, but i don't have any mt8183 to do realtime testing while i'm working on it
<hexdump0815>
i think there is some code missing to probe them properly most probably
<jenneron[m]>
no, it's a mistake in all drivers
<jenneron[m]>
they use acpi way to do that
<jenneron[m]>
should not be difficult to fix
<hexdump0815>
ah - ok - looks like you already looked into this topic :)
<aceridus>
What is the issue with loading modules? Is it only on mt8183 or all devices?
<jenneron[m]>
only mt8183
<hexdump0815>
jenneron[m]: you should have an email :)