On Mon, Jan 31, 2022 at 05:49:14AM -0000, Be wrote: > Hello, > I've been using Fedora on my Pinephone for like 9 months or so and my > Pinephone Pro Explorer Edition just arrived the other day. The original > Pinephone's boot order had the microSD card before the eMMC which made it > really easy to try different OSes. By contrast, on the Pinephone Pro, the > boot order in hardware is: > > 1. SPI flash > 2. eMMC > 3. microSD > > From the factory, there is a u-boot image on the eMMC drive which will boot > an OS from the SD card before the eMMC and there is nothing on the SPI flash. > This is problematic because it's really easy to accidentally get the device > into an unbootable state when installing an OS to the eMMC drive if the > factory uboot build is erased. There is a way to temporarily disable the eMMC > drive in hardware to make it boot from SD, but that's not obvious or > convenient. So, currently, the Pine wiki > (https://wiki.pine64.org/wiki/PinePhone_Pro) advises against replacing the > stock Manjaro OS on the eMMC drive and few distros are providing prebuilt > images. > > People working on different distros have been coordinating how to deal with > this. The plan is to use a fairly new project, Tow Boot, and flash it to the > SPI flash: > https://samuel.dionne-riel.com/blog/2021/05/10/unveiling-tow-boot.html > Putting the platform firmware on the SPI flash chip separate from the eMMC > drive will make the process of installing OSes easier and more foolproof. > Support for the Pinephone Pro in Tow Boot is almost ready with support for > the Pinephone Pro's SPI flash just added today, albeit it needs a little > polishing. Tow Boot on the SPI flash will make the process of installing an > OS similar to x86; distros just need to create a UEFI bootable system and do > not need to worry about shipping platform firmware. Tow Boot also obviates > the need for JumpDrive. Simply pressing the volume up button on boot will > expose the eMMC drive as a USB mass storage device, refer to > https://github.com/Tow-Boot/Tow-Boot/pull/67 for details about the UX design. > Hopefully future Pinephon > e Pro batches will ship with Tow Boot on the SPI flash from the factory, but > for now users will need to install it by booting a Linux system from an SD > card. A Tow Boot installer image like that has already been made for the > Pinebook Pro, so I think one for the Pinephone Pro will be ready to test soon.
So, sadly, I still don't quite understand the boot process on arm devices, but why is tow-boot suggested here instead of just using uboot? ie, whats the advantage of tow-boot here? > This is great new for Fedora because I think it means we can use the normal > Fedora tools for building ARM images to create UEFI bootable images without > needing the scripts in https://github.com/nikhiljha/pp-fedora-sdsetup that > were made for the Pinephone. Using Fedora tooling to build the Pinephone Pro > images opens up the path to smartphone support in upstream Fedora. I've been > digging around in scattered documentation and talking to Conan Kudo on Matrix > and IIUC, the way the upstream images are built is that Punji calls `koji > image-build` which calls livemedia-creator. Please correct me if I've > misunderstood this. I've tried to figure out how to build aarch64 images > locally on my x86-64 laptop and made a bit of progress using Mock with > livemedia-creator as documented at > https://weldr.io/lorax/livemedia-creator.html#using-mock-and-no-virt-to-create-images > arm images are made via imagefactory/oz, depending on what image you are talking about here? There is also work to move imagefactory/oz built images over to ImageBuilder (a image as a service type thing run by Red Hat). > Thanks to the efforts getting Fedora on the original Pinephone, good progress > has been made getting Plasma Mobile and Phosh packaged in upstream Fedora. > There are still a handful of packages in the > https://copr.fedorainfracloud.org/coprs/njha/mobile/ COPR repository that > aren't upstream. I think enough has been upstreamed at this point that we can > start working on base Plasma Mobile and Phosh Kickstart files to use with > livemedia-creator that could eventually make it upstream. For now, we'll > still need device-specific Kickstarts for the downstream kernel packages > which could %include the base Plasma Mobile or Phosh Kickstart. Fortunately > for the Pinephone Pro, distros are coordinating to avoid the fragmentation > that has happened with kernels for the original Pinephone and development > effort is being coordinated on the > https://gitlab.com/pine64-org/linux/-/tree/pine64-kernel-ppp-5.16.y/ > repository. Right. I would think next think we want is to upstream uboot support, then get kernel support in. I have no idea if Fedora kernel maintainers would be willing to carry some/any/all of the patches there, but I think that has a much better chance than the pinephone kernel patches had. ;) Packages are good to get going, but without kernel support we will be doing them as part of a remix like we are now. ;( > > One important feature that we haven't gotten working on the Pinephone is full > disk encryption. One issue blocking this is that Plymouth (the software in > the initrd that asks for the LUKS password) does not have an on screen > keyboard: https://gitlab.freedesktop.org/plymouth/plymouth/-/issues/144 Also, > the Anaconda GUI wasn't designed for small touchscreen devices without a > keyboard. Fortunately this could change with the recently announced rewrite > of the Anaconda GUI: > https://discussion.fedoraproject.org/t/anaconda-is-getting-a-new-suit/35916/15 Yeah, this is kind of hard as we don't typically do full normal installs on arm devices. We do need some way to do the disk encryption however. > Does this seem like a reasonable plan? Is there anything I've overlooked? I think it sounds fine to me (except I don't get the towboot advantage), but I think it's going to be a lot of work, so don't expect something tomorrow. ;) kevin
signature.asc
Description: PGP signature
_______________________________________________ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/arm@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
