search

MichaIng / DietPi

Lightweight justice for your single-board computer!
https://dietpi.com/
GNU General Public License v2.0
4.87k stars 496 forks source link

Image | Pinebook Pro #3932

Closed ravenclaw900 closed 3 years ago

ravenclaw900 commented 3 years ago

Creating an image request

Formal device information

Is the SBC officially supported by the Debian installer?

If not, is a reliable 3rd party Debian image available for this SBC?

To be honest, I don't even think that the original PineBook is available for purchase anymore. The mailing list just redirects to an image of a battery, and there is no price listed.

MichaIng commented 3 years ago

Many thanks for your request. This is a great opportunity to test the official Linux ARMv8 kernel, which supports the Pinebook Pro: https://packages.debian.org/buster-backports/linux-image-arm64

The bootloader needs to come from Bullseye: https://packages.debian.org/bullseye/u-boot-rockchip But that is no problem, has no conflicting dependencies and only needs to be flashed once and can then theoretically be removed. Or we ship a first Debian Bullseye image? Kodi still missing 😢: https://packages.debian.org/kodi

ravenclaw900 commented 3 years ago

Okay, now that I actually have the device and can test stuff out, would you rather I create an own image with debootstrap and install the bootloader/kernel, or use one of the Armbian images (which has a legacy kernel version).

ravenclaw900 commented 3 years ago

When trying to save the created image, I got the error:

Warning! Secondary partition table overlaps the last partition by
30 blocks!
Try reducing the partition table size by 120 entries.
(Use the 's' item on the experts' menu.)
Aborting write of new partition table.

from sgdisk. After trying to fix it by doing what it told me to (though I used gdisk instead of sgdisk), I'm getting:

[FAILED] DietPi-Imager | Unsupported root filesystem type (gpt), aborting...
MichaIng commented 3 years ago

After trying to fix it by doing what it told me to

What exactly did you do? I wonder how to reduce a partition table size. I mean a filesystem and a partition can be resized, but how to do that with a partition table?

Which initial image did you use or how did you create it? sgdisk -e moves/creates the secondary/backup partition table to the end of the disk. So if the device or the img file has exactly the size to just contain the last partition, then there would be no space for the secondary partition table anymore. But an image file with GPT partition table should have that space to not cause those errors.

The unsupported filesystem "gpt" is fixed with: https://github.com/MichaIng/DietPi/commit/f31cfc52d5cbedc58f3dc58e6a339716c4dae574 Wrong variable used 😅. But would be of course interesting which actual unsupported filesystem was found, as ext4, f2fs and btrfs should go through.

ravenclaw900 commented 3 years ago

To try to fix it, I ran gdisk, selected the disk, went to the expert menu by pressing x, and reduced it from 128 to 8. I used https://github.com/daniel-thompson/pinebook-pro-debian-installer for the initial image. What's strange is that it was (and was reported as) an ext4 filesystem. EDIT: Well, now the unsupported filesystem is ()!

MichaIng commented 3 years ago

Here is the partition table: https://github.com/daniel-thompson/pinebook-pro-debian-installer/blob/master/gpt.sfdisk.template It does the EFI-ready partitioning but the bootloader does not support it. Not sure if the empty size for the last (root) partition means that it will automatically reach until the end of the device. Probably sgdisk -e creates the backup table by default with 128 such lines/entries, even when not all are fill with an actual partition, hence the suggestion to remove 120 unused entries? Since "only" 6 are used, that should be fine.

The filesystem is ext4: https://github.com/daniel-thompson/pinebook-pro-debian-installer/blob/master/install-debian#L92 If there was no ext4 partition on the disk, it would not have been shown in the list to select. When selecting the root partition, the filesystem type is again shown and was estimated the same way it was to show the menu 🤔: https://github.com/MichaIng/DietPi/blob/f31cfc52d5cbedc58f3dc58e6a339716c4dae574/.meta/dietpi-imager#L272 So like lsblk -no FSTYPE /dev/sda6 should show the filesystem type. Probably (s)gdisk -e or the partition table change broke the filesystem on the last/root partition?

MichaIng commented 3 years ago

I created an image now: https://dietpi.com/downloads/images/DietPi_PinebookPro-ARMv8-Buster.7z It's again based on Armbian kernel, dtb and bootloader packages. I re-evaluated the situation and currently the Debian packages have downsides as well, e.g. only low number of SBCs is supported by those U-Boot packages, the device tree files need to be "installed" manually, as well as the kernel, meaning that new versioned files are not automatically moved to a generic file name which can then be used in the U-Boot configs. The kernel itself is pretty much the same, I also compared important kernel configs, there is not much differences, and both basically use nearly untouched upstream Linux.

I however removed the Armbian tweaks and tools package and replaced two important scripts it contains (converting initramfs into U-Boot format and cleaning up old U-Boot formatted uInitrd files on upgrades) with own ones. So we have much less overhead to deal with the services and configs that Armbian ships, which conflict with our own or are not wanted for other reasons. But I have to say, their kernel+dtb+bootloader and respective configuration setup is pretty good. I'll contribute a little to the defaults. The migration to Debian kernel packages is then not as urgent anymore and I'll use some more time to think about own setup and config scripts to make this running smoothly and easy configurable, for the boards which are supported by Debian U-Boot packages as well.

Ah, that image is single-partition without EFI. Not sure if there is any pre-installed UEFI-like firmware on Pinebook Pro that would make an UEFI image a reasonable option?

ravenclaw900 commented 3 years ago

You can flash U-boot to the SPI chip inside of the Pinebook Pro, but it is not installed by default. However, an EFI partition, while it can be created, is not current used. Anyway, I did some preliminary testing, and the image seems to work well. I'll do some more this afternoon.

MichaIng commented 3 years ago

You can flash U-boot to the SPI chip inside of the Pinebook Pro

Ah yes I remember this from some Odroids as well. It is a potential issue when not the intended bootloader, flashed to the beginning of the root drive, is loaded, when the one from the SPI does not load the U-Boot config /boot/boot.scr as required. If I'm not mistaken there is a key combination to hold at boot to force skipping the SPI bootloader? Then we could find out and document how to flash the one from Armbian to SPI and add that to our documentation.

Another thing is the internal eMMC, where it would be awesome if we provided a way to flash DietPi directly to it. First I thought about wrapping a DietPi image into a slimmed down DietPi installer image which only loads a script at boot that allows to select the internal target drive, e.g. the eMMC to flash the wrapped image to. Then I thought about another way:

I haven't fully through through this, but if it worked, that would be awesome 😃.

ravenclaw900 commented 3 years ago

Alright, so the image still works well, but there are some error messages on boot, which seem like they might be problems.

dietpi@DietPi:~$ dmesg -l err,crit,alert,emerg
[    2.982474] mmc1: tuning execution failed: -5
[    2.982888] mmc1: error -5 whilst initialising SD card
[    3.113193] mmc1: tuning execution failed: -5
[    3.583767] rockchip-pcie f8000000.pcie: PCIe link training gen1 timeout!
[   10.395264] cw2015 4-0062: Failed to register power supply
[   10.406540] cw2015 4-0062: Failed to register power supply
[   10.457050] cw2015 4-0062: Failed to register power supply
[   10.474611] cw2015 4-0062: Failed to register power supply
[   10.478999] OF: graph: no port node found in /i2c@ff3d0000/fusb30x@22
[   10.549238] rockchip-dp ff970000.edp: no DP phy configured
[   10.628962] bootsplash: Failed to initialize.
[   10.711913] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43456-sdio for chip BCM4345/9
[   10.922013] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43456-sdio for chip BCM4345/9
[   10.922169] brcmfmac: brcmf_c_process_clm_blob: no clm_blob available (err=-2), device may have limited channels available
[   10.922610] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4345/9 wl0: Feb 11 2020 11:54:51 version 7.45.96.61 (be7af2d@shgit) (r745790) FWID 01-a41d86bd es7.c5.n4.a3

However, I will look into an installer image/setting, as that does sound neat.

MichaIng commented 3 years ago

I'll have a look through these errors. To start with one I know what it's about:

[ 10.628962] bootsplash: Failed to initialize.

Interesting, that should be disabled by default, or, ah, probably on Pinebook it is not. Can you try:

G_CONFIG_INJECT 'bootlogo=' 'bootlogo=false' /boot/armbianEnv.txt

EDIT: Fix for the bootlogo. I'll update the image as well: https://github.com/MichaIng/DietPi/commit/4ae25a2632004ed1166934c44cf9c21ca8d49c06

MichaIng commented 3 years ago

Found an old issue where exactly this SPI bootloader issue occurred: #3305 So there is a tool collection to flash or erase an SPI bootloader: https://packages.debian.org/mtd-utils This would fit into device-specific boot troubleshooting docs, as planned here: https://github.com/MichaIng/DietPi-Docs/issues/396

ravenclaw900 commented 3 years ago

@MichaIng, were you thinking something like this for the OS reflashing?

MichaIng commented 3 years ago

Yes something like this. Since the rootfs is mounted already, it need to be mount -o remount,ro /, which sadly fails sometimes with "device is busy" for some reason. The same needs to be done with the /boot partition, if it exists. Alternatively, as an own service, it could run before systemd-remount-fs.service, where the rootfs is still mounted read-only (right after systemd-fsck) and no other filesystem is mounted yet. /boot could then be mounted to read settings. But again, then we had no network, hence not an option a headless SBC, as long as we do not implement reading and applying network settings from dietpi.txt as well.

findmnt -Ufnro SOURCE -M / would only be the root partition, while the whole drive needs to be cloned:

if="$(lsblk -npo PKNAME "$(findmnt -Ufnro SOURCE -M /)")"

And then, since device names and IDs are not predictable, an interactive selection needs to be possible, hence a whiptail, similar to the one in DietPi-Imager to select the source drive.