**** BEGIN LOGGING AT Sat Jan 22 02:59:56 2022 Jan 22 06:59:58 Morning! Jan 22 07:00:06 Tofe: Seems Megi's been busy :) https://megous.com/git/linux/log/?h=orange-pi-5.16 Jan 22 07:01:28 Had some discussion and he'll fix the POWER_SUPPLY_ONLINE=0 as well soon, so nyx-modules will be happy. He was arguing it's "not documented" in kernel code. I told him there were about 15 targets we tested in the past and only PPP didn't work, so he agreed to change it ;) Jan 22 07:53:55 Morning! Jan 22 07:53:59 Herrie: nice ! Jan 22 07:55:22 Tofe: I don't have my keyboard yet, seems Pine ran out of TPU cases so my order was a little delayed Jan 22 07:55:57 We'll have to get used to this "out of stock" messages in the coming months, I guess Jan 22 07:56:09 Should be shipped next week, so it's good Megi put the required bits in kernel already Jan 22 07:56:29 Tofe: Well seems stock levels on site were off according to Lukasz Jan 22 07:56:32 ah just a week well that's fine Jan 22 07:56:38 So they oversold Jan 22 07:56:55 Well I ordered on 1st of January so should have arrived already Jan 22 07:57:10 But anyway away till 28th so it's fine Jan 22 07:57:37 Did we try LuneOS with a BT keyboard, by the way ? Jan 22 07:57:49 Like the one HP used to sell Jan 22 07:57:54 Tofe: Not sure I think it should work Jan 22 07:58:04 I recall testing it long time ago Jan 22 07:58:13 I have some of those laying around Jan 22 07:58:24 me too, I could give it another try someday Jan 22 07:58:37 But this kb goes via pogo and has battery Jan 22 07:58:49 So nyx will need some updating Jan 22 07:59:00 And the rest too probably Jan 22 07:59:15 Because nyx-modules can only deal with 1 battery Jan 22 08:00:15 But will look into that when I got something in hands Jan 22 09:46:44 Herrie and/or Tofe: have you seen the discussions about tow-boot yesterday in the cross distro kernel channel? Jan 22 09:47:13 Yeah I've seen it Jan 22 09:47:32 I don't know too much details about it to say anything useful to be honest Jan 22 09:47:41 me too, but I didn't look yet at what tow-boot was Jan 22 09:48:00 Hmm well I'd like to get all distributions to agree on using this so we can reliably use it and not have other distributions that don't use it overwrite an already installed tow-boot installation Jan 22 09:48:11 Ok I'll try and explain in detail what it is and does Jan 22 09:50:47 PureTryOut[m]: for pinephone I have no real argument for using something over something else, as long as the project behind it is stable and free software Jan 22 09:50:50 Basically, tow-boot is a pre-configured u-boot. Rather than every distribution shipping their own u-boot the goal is to take the u-boot (so called "platform firmware") responsibility out of distribution hands and give it to a dedicated "platform firmware provider" instead, which in this case is tow-boot. It means that the user will have to flash tow-boot once themselves (assuming it doesn't get shipped from the factory on a dedicated Jan 22 09:50:50 SPI module) and they can then install any EFI/extlinux compatible distribution/bootloader. Things like GRUB multi-booting distros becomes _very_ easy and entirely possible with this Jan 22 09:52:07 The problem with the PP and PPP is that right now they don't have a dedicated SPI module however, so a tow-boot installation will have to live on the internal storage. This can work but since that internal storage is shared with distribution installations, those distributions have to take care to not overwrite the installed tow-boot. Right now I'm trying to get confirmation of all distributions to use tow-boot like this so we can rely Jan 22 09:52:07 on nobody overwriting it and tow-boot always being there Jan 22 09:52:29 And yes tow-boot is entirely free software. The build scripts are MIT and the compiled binary is GPL-2.0 Jan 22 09:52:56 I'm already using it on my PPP right now, and it has had releases for devices like the PBP and RockPro64 for a while as well Jan 22 09:53:33 From a distribution point of view the main benefit is not having to care about u-boot, ATF and Crust anymore. That is all handled by this platform firmware provider, tow-boot Jan 22 09:54:02 Eventually when devices get fully mainline Linux support you can generate 1 image that boots on multiple devices like that. Imagine 1 image for both the PP and PPP Jan 22 09:54:26 PureTryOut[m]: but at some point, tow-boot has to be installed though Jan 22 09:54:28 Thoughts? Any reason you would not be in favor of this approach and how we can get you to change your mind? 😄 Jan 22 09:54:58 Yes. Ideally the factory does this on a dedicated SPI module but if the device doesn't have this, like the PP and PPP right now, the user will have to do it themselves once. Luckily it's very easy, https://tow-boot.org/getting-started.html Jan 22 09:56:14 From our build perspective we are quite flexible and agnostic, we can build pretty much anything, so I don't really see an issue there. I see the advantages of tow-boot Jan 22 09:56:46 Then again tow-boot is still uBoot in some sense if I understood it correctly, just with a different purpose and identity Jan 22 09:57:24 It is u-boot yes, just pre-configured Jan 22 09:57:49 same here, I see no problem with this; we'll have to rework the boot sequence, as we don't use any EFI so far, but I guess yocto can help there Jan 22 09:57:59 The main thing is that it takes responsibility of maintaining and updating it away from distributions. And what distribution wouldn't love that? 😉 Jan 22 09:58:25 PureTryOut[m]: well, someone has to build it, though Jan 22 09:58:32 Ah that's good to know, thanks. I'm trying to convince all distros right now so hopefully we can get Pine64 to ship an SPI module again. Even if they don't then this would still benefit all distributions in shared storage mode Jan 22 09:58:40 Tofe: yes but the tow-boot project will do that, like they do already Jan 22 09:59:59 We don't have to deal with patches to u-boot anymore and figuring out if things still work on that level, we just care about the Linux distro like on x86 machines Jan 22 10:01:14 Tofe: Seems we don't need to have (U)EFI per se... extlinux should also work, though (U)EFI is preferred Jan 22 10:01:24 PureTryOut[m]: in the PP usecase, where is two-boot installed ? on eMMC ? Jan 22 10:01:29 There should be bits for this in Yocto really Jan 22 10:01:34 our image uses extlinux and works just fine Jan 22 10:01:42 Tofe: it would be installed to eMMC Jan 22 10:01:59 Note that right now I'm mainly advocating for use on the PPP, but I definitely want it to work the same on the PP as well Jan 22 10:02:27 but if a sdcard is inserted, won't it look there first ? Jan 22 10:03:28 (which is the main dev usecase) Jan 22 10:04:24 in case of the PP yes. On other devices the device will look on eMMC first, where tow-boot is then installed and takes over, and if the user wants to boot from sdcard they can hold the volume down button while booting Jan 22 10:05:16 The main use on the PP would be being able to create one image for multiple devices including the PP. The bigger benefit on the PPP is not having the distro accidentally brick the device anymore and easy booting from sdcard Jan 22 10:05:22 Though I guess that if on the sdcard there is just extlinux, it won't boot off of that Jan 22 10:05:38 true Jan 22 10:05:49 it'll still boot with tow-boot on eMMC in that case Jan 22 10:06:35 basically the whole booting experience becomes way more like on PC. Boot from internal storage by default and if some other boot medium needs to be used the user just presses a button. But rather than mashing escape on the keyboard you press volume down instead lol Jan 22 10:07:22 yep, I see; it's also quite similar to fastboot in some way Jan 22 10:08:12 I suppose yes Jan 22 10:08:14 but we'll need to create a dedicated partition on eMMC, right ? Jan 22 10:08:24 for LuneOS? or tow-boot? Jan 22 10:08:29 tow-boot Jan 22 10:08:51 for the distro I see quite clearly what we'll need Jan 22 10:08:57 PureTryOut[m]: We have stuff like fwupd, grub-efi, gnu-efi and others readily available in Yocto. Jan 22 10:08:57 well if "we" means LuneOS, then no you don't. The tow-boot installation procedure already takes care of that. As LuneOS you just need to not overwrite that one partition Jan 22 10:09:22 Yeah I hope we can add support for updating tow-boot to fwupd. We have smart people like Dylan van Assche which can do that luckily Jan 22 10:09:33 and yes you could use grub to boot, but extlinux works fine too Jan 22 10:09:34 ah, "we" meant whoever wants two-boot installed Jan 22 10:09:40 tow* Jan 22 10:09:46 Well for PPP we currently use the following WIC for the partition layout: https://git.yoctoproject.org/meta-rockchip/tree/wic/rockchip.wks Jan 22 10:10:43 Herrie: we already use extlinux for our qemu-x86 image, don't we ? Jan 22 10:10:53 Tofe: Yeah I believe so yes Jan 22 10:11:15 Pretty sure I've seen it on my VBox console Jan 22 10:11:50 PureTryOut[m]: ok, I'll need to read a bit about a concrete tow-boot installation Jan 22 10:13:21 in the end both the user and the distro should want tow-boot installed. The user gets a PC-like booting experience and the distributions can make generic images for multiple devices, just like on x86 Jan 22 10:14:16 So a bit like GSI on Android side? Jan 22 10:14:45 I suppose. I'm not that familiar with Android Jan 22 10:15:06 I like to compare it more to x86. My distro doesn't know on what device I'm going to run it and they don't care. Since they can boot with UEFI, it'll work Jan 22 10:15:27 Well basically a generic system image that's supposed to work independent of vendor and device Jan 22 10:15:28 once the device is fully supported in mainline it removes a lot of burden from the distribution maintainers Jan 22 10:15:36 then yes I suppose Jan 22 10:15:51 You still have kernel & device specific firmware, but that should be it Jan 22 10:15:59 I'm also not too familiar with it to be honest Jan 22 10:18:06 device-specific firmware would be a bit like linux-firmware. You can install it on all devices, they'll just use what they need from it Jan 22 10:18:26 Well we still have to tweak things per-device, like DPI and such Jan 22 10:19:01 I'd hope the DE and stuff could take care of that. We don't ship LuneUI of course but for at least Plasma Mobile we already don't set DPI per device, it figures that out by itself Jan 22 10:19:40 Maybe we could do that too, we never really tried Jan 22 10:20:27 Unlike Plasma Mobile, or ubports, LuneOS doesn't come from a generic distro codebase, it has always been device-specific Jan 22 10:20:33 Well since Pine64 devices don't run fully on mainline yet you'll have to make device-specific images for the forseeable future anyway, so there is no haste there Jan 22 10:20:43 Oh damn, too bad Jan 22 10:21:24 Tofe: Well SFOS is doing that too, so is UBPorts in a way with their overlays Jan 22 10:21:32 Doesn't mean that 90% cannot be generic Jan 22 10:21:46 At the time (15 years ago), going generic on embedded devices was just a unrealistic dream Jan 22 10:21:47 Which is what we're doing on build server actually with the sstate-cache Jan 22 10:22:02 PureTryOut[m]: On our build server we actually reuse a lot Jan 22 10:22:12 Well hopefully over time this can improve on your side too 😄 Jan 22 10:22:38 Herrie: yes, I'm not saying we don't shared anything between our builds :p Jan 22 10:22:40 We build things once per architecture and reuse where possible so we don't need to rebuild stuff a lot of times Jan 22 10:22:54 But yeah for now immediate benefit is distribution not having to deal with u-boot and ATF and stuff anymore Jan 22 10:23:13 Well for us uBoot, ATF and crust are not really a pain Jan 22 10:23:18 Except for when things break Jan 22 10:23:32 See that's the thing, you don't have to worry about it breaking anymore, that's not your responsibility anymore Jan 22 10:24:09 I'm just wondering about the transition: should we have a way to install tow-boot at first boot if we don't detect it ? Jan 22 10:24:47 like dd'ing the img to emmc or so Jan 22 10:25:14 I guess the main difference is that OE is a tool to easily create custom linux distros, creating different PP and PPP image isn't as anoying as it is for generic distro providers Jan 22 10:25:17 nope, definitely don't do that Jan 22 10:25:41 new OS instructions will first just point the user to https://tow-boot.org/getting-started.html Jan 22 10:26:29 once they finished that, they'll come back to the distro installation instructions Jan 22 10:26:38 PureTryOut[m]: ah ok I misunderstood, tow-boot knows how to install itself Jan 22 10:26:42 ideally Pine64 re-adds SPI flash and flashes tow-boot to it from the factory Jan 22 10:26:45 yeah it does Jan 22 10:27:08 https://tow-boot.org/getting-started.html is only needed when the device doesn't have tow-boot installed yet, either in SPI or shared storage Jan 22 10:27:44 this way we'll never have to worry about bricking a device from the distro side, we just don't touch tow-boot Jan 22 10:27:47 yes, I just thought the user needed to dd himself to emmc, which can be a difficult task on a phone where nothing is there yet Jan 22 10:27:47 linux-firmware is the biggest package in all ubuntu installs I have and in couple of them it's not needed at all (and is included by default just to keep the image generic) Jan 22 10:28:26 Tofe the shared storage mode includes instructions from that. Basically first flash tow-boot to a sdcard, boot that, then use that to enable a jumpdrive-like mode and use that to flash tow-boot to internal storage. But yeah just a 1-time thing Jan 22 10:28:53 JaMa: my distribution splits linux-firmware in tons of subpackage so if needed/wanted the end-user can install just what they need Jan 22 10:28:59 JaMa: this week Archlinux has splitted this package, to ease the updates Jan 22 10:30:23 that's nice, OE does that since linux-firmware recipe was created, but with added benefit that the BSP (MACHINE.conf) can decide which firmwares make sense for given hardware (so PP and PPP images can easily ship with only required bits) Jan 22 10:30:25 PureTryOut[m]: yes, this procedure is completely fine Jan 22 10:30:32 Awesome! Jan 22 10:30:41 So can I count you guys as on-board? Jan 22 10:31:11 PureTryOut[m]: yep, I'm fine Jan 22 10:31:45 awesome! /me goes on to the next distribution and notes you down as on-board Jan 22 10:31:51 :) Jan 22 10:32:10 Btw for any tow-boot related questions, there is #Tow-Boot:matrix.org. I don't think it's bridged to IRC though Jan 22 10:32:40 I'm on matrix too, just have to open the channel Jan 22 10:33:08 Awesome 👍️ Jan 22 10:35:49 JaMa: We have some specific ones for PP and PPP Jan 22 10:36:17 Tofe: https://archlinux.org/packages/core/any/linux-firmware/ shows 9 split packages, https://git.openembedded.org/openembedded-core/tree/meta/recipes-kernel/linux-firmware/linux-firmware_20211216.bb has 100+ packages Jan 22 10:36:47 JaMa: yes, they just excluded the big ones, mainly Jan 22 10:37:33 I mean I basically put everything in a single recipe for now with regards to Pine64 firmwares: https://github.com/webOS-ports/meta-pine64-luneos/blob/master/recipes-kernel/linux/linux-firmware-pine64_1.0.bb Jan 22 10:41:38 you can in theory reuse some of the bits from linux-firmware recipe, like rpi combines that with rpi specific firmware, but that's not without it's own issues like in https://github.com/agherzan/meta-raspberrypi/commit/3623b89c53880f00ff0c8fbed895eb665f1374e4 where meta-raspberrypi needs to be updated to match updated packaging of linux-firmware Jan 22 10:43:05 my point was just that we don't really need the images to be generic, shipping pre-configured u-boot with wic isn't big deal when we will still produce MACHINE-specific images to be able to include only the necessary bits (like different firmware files for each MACHINE image) Jan 22 10:44:11 even Raspberry Pi OS on the other hand doesn't take advantace of newer CPU cores in latest rpi, just because it would be pain to build and test different images for different pis Jan 22 10:45:56 JaMa; Yeah I saw that approach and thought seeing the small number of files involved, it was just easier to put them in a single recipe like this. Jan 22 10:57:22 It's true there is no real pressure with Yocto to have a generic image (and with non-mainlined devices it might still be unrealistic) Jan 22 11:00:30 with some exceptions like those mesa drivers we had to unify for PP and PPP, because rebuilding qtwebengine and everything is too much to save installing small extra mesa driver Jan 22 11:01:34 yup Jan 22 11:02:32 but I find the tow-boot initiative interesting independently from that, it could help push the pinephone a bit more :) Jan 22 11:03:19 agreed Jan 22 11:03:21 for us it's just migrating from u-boot to extlinux, probably not a big deal when I find the related documentation Jan 22 11:03:37 or just supporting 2 IMAGE_FSTYPES Jan 22 11:04:14 wic which will include everything (and overwrite possible tow-boot) and single partition image with just rootfs Jan 22 11:05:09 then someone can create something like PINN on top of tow-boot for easy trials for various distros Jan 22 11:05:34 PINN? Jan 22 11:05:47 https://github.com/procount/pinn Jan 22 11:06:10 PINN Is Not NOOBS https://forums.raspberrypi.com/viewtopic.php?t=142574 Jan 22 11:06:39 yes https://github.com/procount/pinn Jan 22 11:06:55 ok, yes, looks nice :) Jan 22 20:29:02 Tofe/JaMa: What are your thoughts on creating a repo on GitHub where we can push the halium builds to, so we can use those in the builds? Anyone now trying to build is facing issues with the files not being available Jan 22 20:38:38 JaMa: uh the goal is to not have distros overwrite tow-boot, _please_ don't touch it. Especially on the PPP that's a dangerous operation and if it goes wrong you leave the device bricked Jan 22 20:39:41 that's why there would be the rootfs image for people who don't want to risk it Jan 22 20:39:59 Herrie: no objection from me Jan 22 20:41:41 JaMa: OK, I'll put something up for it tomorrow I guess then Jan 22 20:41:52 providing such an image that does overwrite it sure, but please make it clear it's not the prefered option and only for people that know what they are doing 😅 Jan 22 20:42:08 I hope we can get Pine64 to add SPI flash to future PPP editions (post EE) so this isn't a problem anymore **** ENDING LOGGING AT Sun Jan 23 02:59:56 2022