hexdump01 has joined #linux-cros-arm
hexdump0815 has quit [Ping timeout: 480 seconds]
<jenneron[m]> we now have prebuilt images https://files.open-rt.party/postmarketOS-Images/
<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
hexdump01 has quit [Quit: WeeChat 1.9.1]
hexdump0815 has joined #linux-cros-arm
<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 :)
<jenneron[m]> it seems that someone tested kappa https://wiki.postmarketos.org/wiki/HP_Chromebook_11a_(google-kappa)
<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
<jenneron[m]> aceridus: there is https://github.com/labwc/labwc
<jenneron[m]> it's packaged in alpine
<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 :)