Skip to content
This repository has been archived by the owner. It is now read-only.

Add Raspberry Pi device #1501

Merged
merged 4 commits into from May 29, 2018

Conversation

Projects
None yet
6 participants
@drebrez
Copy link
Member

commented May 16, 2018

Added a new deviceinfo variable deviceinfo_boot_filesystem to specify the desired filesystem for the boot partition.
In pmb/install/format.py it checks if it's a supported value otherwise it raises an exception. Supported for now: fat16 and ext2 (default).
In order to format in fat16, there is the additional package dosfstools (132 kB) installed in the native chroot.

About the Raspberry Pi device files, when you select it in pmbootstrap init it will prompt you which kernel to use, this depends on the device version there is a different kernel for it.

[10:47:03] Which kernel do you want to use with your device?
[10:47:03] Available kernels (2):
[10:47:03] * rpi: Kernel for the Raspberry Pi Zero & 1
[10:47:03] * rpi2: Kernel for the Raspberry Pi 2 & 3

The config.txt and cmdline.txt files are taken from the official alpine raspberry pi download (http://dl-cdn.alpinelinux.org/alpine/v3.7/releases/armhf/alpine-rpi-3.7.0-armhf.tar.gz), with the path adapter to our kernel/initramfs location.

In the post-install scripts there is the necessity to copy the .dtb and .dtbo files installed by the kernel package to the /boot and /boot/overlays folders. Those are required in order to boot the device.

Tested:

  • Raspberry Pi Zero W (steamport, yangxuan8282 )
  • Raspberry Pi 1 Model B (duncan^)
  • Raspberry Pi 2 Model B (drebrez)
  • Raspberry Pi 3 (MartijnBraam)

Todo:

Closes: #699


[x] Merge on GitHub (see https://postmarketos.org/merge)

kernel=vmlinuz-rpi2
initramfs initramfs-rpi2
[all]
include usercfg.txt

This comment has been minimized.

Copy link
@MartijnBraam

MartijnBraam May 17, 2018

Member

How does the rpi handle an include to a non-existent file? If it just ignores that it would be nice to include a third config file so you can put extra config in there with another package

This comment has been minimized.

Copy link
@drebrez

drebrez May 17, 2018

Author Member

@MartijnBraam I've included that file, like suggested in the rpi alpine wiki (https://wiki.alpinelinux.org/wiki/Raspberry_Pi), see the Note there

This comment has been minimized.

Copy link
@MartijnBraam

MartijnBraam May 17, 2018

Member

I meant adding another include below the usercfg.txt so that you can also set config options through packages. like adding include pkgcfg.txt and adding that to a digital signage package to disable stuff like overscan.

This comment has been minimized.

Copy link
@drebrez

drebrez May 17, 2018

Author Member

@MartijnBraam now I see what you mean, but why not extending the functionality when somebody actually needs it?
I'm not a huge fan of implementing stuff that maybe in future it will be used.
But it should be easy to test if adding an include of a missing file it breaks or not.


# Bootloader related
deviceinfo_flash_method="none"
deviceinfo_boot_filesystem="fat16"

This comment has been minimized.

Copy link
@MartijnBraam

MartijnBraam May 17, 2018

Member

I'm seeing both fat16 and fat32 mentioned on the internet for the rpi boot partition are you sure we need fat16?

This comment has been minimized.

Copy link
@drebrez

drebrez May 17, 2018

Author Member

@MartijnBraam I've tried with FAT32 but my rpi (model 2 B) refuses to read it, dunno why

deviceinfo_keyboard="true"
deviceinfo_external_storage="true"
deviceinfo_screen_width="1280"
deviceinfo_screen_height="720"

This comment has been minimized.

Copy link
@MartijnBraam

MartijnBraam May 17, 2018

Member

I think it might be better to set this to 1920x1080 since we don't have that much initfs size concerns on the pi

This comment has been minimized.

Copy link
@drebrez

drebrez May 17, 2018

Author Member

@MartijnBraam I wasn't sure which resolution to put, but I agree to increase it to 1920x1080

deviceinfo_date=""
deviceinfo_dtb=""
deviceinfo_modules_initfs=""
deviceinfo_arch="armhf"

This comment has been minimized.

Copy link
@PureTryOut

PureTryOut May 17, 2018

Contributor

This is fine for everything up to the RPi2, but the RPi3 should be able to run on aarch64 (booting might be a bit of an issue though), don't we want that?

This comment has been minimized.

Copy link
@drebrez

drebrez May 17, 2018

Author Member

@PureTryOut @MartijnBraam from what I understood, the RPi3 runs with the same kernel as the RPi2, and in alpine repo it's only built for armhf (https://pkgs.alpinelinux.org/packages?name=linux-rpi2&branch=edge)

This comment has been minimized.

Copy link
@PureTryOut

PureTryOut May 17, 2018

Contributor

I think on Alpine and Raspbian it indeed uses the same kernel, but we could change that no? The device has the capability to run in 64-bit mode, I would think it's a waste to not use that.

This comment has been minimized.

Copy link
@drebrez

drebrez May 17, 2018

Author Member

@PureTryOut probably it's easier to create a dedicated device package with a custom kernel

This comment has been minimized.

Copy link
@PureTryOut

PureTryOut May 17, 2018

Contributor

Agreed. If we go for that approach, this PR seems fine to me.

@ollieparanoid
Copy link
Member

left a comment

Awesome work @drebrez! With the resolution increased to 1080p and people confirming that it works for the various pi versions, I think this is ready to go.

It's really nice how you've combined multiple raspberry pi versions into one device package and use Alpine's kernels for it 🎉

(The Travis CI error was related to Travis building mesa for armhf, and running out of time, because I've added mesa yesterday as it got an important fix for wayland but that new version isn't built for armhf yet in Alpine. As of now, there's a binary package in the pmOS repos. I've restarted the travis job, it should go through now.)

@ollieparanoid

This comment has been minimized.

Copy link
Member

commented May 17, 2018

Oh, actually the second Travis instance failed for a different reason:

RuntimeError: Invalid kernel subpackage name 'rpi', valid: ['downstream', 'qcom', 'stable', 'mainline']

This can be fixed by adding the new kernels to valid_subpackages = ["downstream"] in test/test_aports.py.

@@ -24,9 +24,15 @@
def format_and_mount_boot(args):
mountpoint = "/mnt/install/boot"
device = "/dev/installp1"
logging.info("(native) format " + device + " (boot, ext2), mount to " +
filesystem = args.deviceinfo["boot_filesystem"] or "ext2"

This comment has been minimized.

Copy link
@ollieparanoid

ollieparanoid May 17, 2018

Member

https://travis-ci.org/postmarketOS/pmbootstrap/builds/379978385#L3013:

KeyError: 'boot_filesystem'

This can be fixed by adding it to pmb.config.deviceinfo_attributes.

This comment has been minimized.

Copy link
@drebrez

drebrez May 18, 2018

Author Member

done

@MartijnBraam

This comment has been minimized.

Copy link
Member

commented May 18, 2018

It works great on the rpi3

@yangxuan8282

This comment has been minimized.

Copy link
Contributor

commented May 19, 2018

tested on rpi 3 , the wifi work (got some issues on eth0)
should add dosfstools to the depends of device-raspberry-pi, otherwise the /boot partition won't mount after boot
seems the boot partition can't mount after boot even with dosfstools installed
update: I use another rpi3 and sdcard install pmos again, after reboot several times both first partition can be mounted and eth0 work properly, seems previous issues should caused by the devices or sdcard

@yangxuan8282

This comment has been minimized.

Copy link
Contributor

commented May 20, 2018

@drebrez there are a package for raspberry pi 3B built-in bluetooth:
https://github.com/yangxuan8282/rpi-aports/blob/master/pi-bluetooth/APKBUILD

not sure if you are interested, in that repos there are also some other drivers and packages for rpi
that package basically is take from aur package pi-bluetooth

and I think we should add a udev rules to device-raspberry-pi, to avoid sudo when using software which use /dev/vchiq (like omxplayer)

#/etc/udev/rules.d/raspberrypi.rules
SUBSYSTEM=="vchiq|input", MODE="0777"
KERNEL=="mouse*|mice|event*",  MODE="0777

and if we can create a PR to ask alpine upstream enable CONFIG_DRM_VC4 for linux-rpi, then we can use drm backend for weston and plasma mobile( it did work on rpi, although quite slow, and tend to crash soon ), the drm backend should more stable then use the fbdev backend

@ollieparanoid

This comment has been minimized.

Copy link
Member

commented May 20, 2018

Great feedback @yangxuan8282, adding dosfstools and the udev rule sounds like a good idea!

I think it makes sense to upstream the pi-bluetooth aport directly to Alpine, as well as making another PR to enable CONFIG_DRM_VC4. Do you want to do that?

Regarding the aarch64 for pi 3 discussion: as I understand we could simply compile the rpi2 kernel for aarch64, right? So someone with a rpi3 could do the following (outside of the scope of this PR):

  • copy Alpine's linux-rpi aport to pmbootstrap/aports/temp/linux-rpi
  • add aarch64 to arch= in the APKBUILD
  • copy the kernel config config-rpi2.armhf to config-rpi2.aarch64
  • pmbootstrap checksum linux-rpi
  • pmbootstrap build linux-rpi --arch=aarch64
  • copy the kernel to the boot partition of a pi3 and try it out
  • when it all works, make a PR to Alpine for this change
  • make a PR on top of this one with a new pi3 aarch64 device

(rebased the PR, so travis runs through with the updated binutils)

@ollieparanoid ollieparanoid force-pushed the device/raspberry-pi branch from 4bea86d to cea71f6 May 20, 2018

@yangxuan8282

This comment has been minimized.

Copy link
Contributor

commented May 20, 2018

@ollieparanoid
There are two blog about rpi3 Alpine 64bit kernel:

https://a-delacruz.github.io/ubuntu/rpi3-setup-64bit-kernel

https://a-delacruz.github.io/alpine/alpine-linux.html

He using the downstream kernel, and use the bcmrpi3_defconfig.

@ollieparanoid ollieparanoid force-pushed the device/raspberry-pi branch from cea71f6 to 20419f2 May 20, 2018

@yangxuan8282

This comment has been minimized.

Copy link
Contributor

commented May 22, 2018

@ollieparanoid
just found a web site, if that record is correct, then we may have some clue to build raspberry pi 3 64 bit kernel for alpine/pmos

this pages is for rpi3:

seems we should able to boot rpi3 with mainline kernel:

  • defconfig (that is arch/arm64/configs/defconfig) in 64 bit mode, and after compare to raspberry pi wiki, that config file did already have rpi3 support

  • bcm2835_defconfig in 32 bit mode

the rpi2 pages is this, for other rpi models ( like zero/zero w, A+, B+) I'm not quite sure, but bcm2835_defconfig maybe also works

the alpine linux-rpi is kind of outdated, which is still 4.9.y and missing some modules for pi

maybe we can build a new mainline kernel package for rpi family, based on APKBUILD of linux-vanilla, use defconfig, multi_v7_defconfig and bcm2835_defconfig as config file

Downstream kernel from raspberry pi foundation maybe a better choices, since it should have better support, but I don't have clue how to build a alpine/pmos package with it.

@ollieparanoid

This comment has been minimized.

Copy link
Member

commented May 22, 2018

@yangxuan8282: cool, I've put what you wrote about pi3 and aarch64 into #1507 and the bluetooth packaging in #1508 so we can continue discussing it there. After reading your dosfstools comment again and looking at the packaged files I don't think it's required to mount /boot.

@drebrez: what do you think about adding the udev rule to device-raspberry-pi?

@steamp0rt, @duncanguthrie: how is the Pi Zero W and Pi 1 Model B testing going?

@steamp0rt

This comment has been minimized.

Copy link
Contributor

commented May 22, 2018

@ollieparanoid haven't got it to boot on zero W yet

@yangxuan8282

This comment has been minimized.

Copy link
Contributor

commented May 23, 2018

@ollieparanoid
you are right, after check again, I found the dosfstools is not necessary as a depends

@drebrez

This comment has been minimized.

Copy link
Member Author

commented May 23, 2018

@steamp0rt I don't know what's wrong with your RPI Zero W because @yangxuan8282 mentioned (#1507 (comment)) that it works on it.

About the udev rule, I've found around in some rpi forums some different rules, like giving the permission to the group video instead of everyone. (See https://www.raspberrypi.org/forums/viewtopic.php?t=7104&start=25#p97393)
Edit: just found out that @MartijnBraam also suggested this in chat

@ollieparanoid

This comment has been minimized.

Copy link
Member

commented May 24, 2018

About the udev rule, I've found around in some rpi forums some different rules, like giving the permission to the group video instead of everyone.

+1 for that

@yangxuan8282 wrote in #1507 (comment):

update: test on rpi 3b+, not boot

What exactly does not work? If the normal raspberry pi 3 works with this PR (as it was already tested), I guess we would need to change the kernel packaged in Alpine to make it work with the 3B+ as well. This sounds like something that should be done outside of this PR (but I think we should mention this when updating the wiki article).

BTW, you seem to have a lot of different raspberry pi versions - do you by chance also have the RPi 1, which is still missing in the test list from the first post?

@yangxuan8282

This comment has been minimized.

Copy link
Contributor

commented May 25, 2018

@ollieparanoid
on raspberry pi 3b+ the green LED keep blinks. It seems the upstream raspberrypi-bootloader is kind of outdated, which is 1.20171029-r0, while the 3b+ release in 2018 march. So the bootcode.bin can't recognize 3b plus. And the APKBUILD of raspberrypi-bootloader source section is too overkill, we just need 3 binary file, but it will grab over 100MB archive. We can just download the file we need directly. So I think we can create a PR to upstream, modified the APKBUILD to:

pkgname=raspberrypi-bootloader
pkgver=20180518
_commit=a46b1f9521229ec26a1377aab7d013df1ade2791
pkgrel=1
pkgdesc="Bootloader files for the Raspberry Pi"
url=https://github.com/raspberrypi/firmware
arch="armhf"
license="custom"
depends=""
makedepends=""
install=
options="!check !strip"
source="$url/raw/$_commit/boot/bootcode.bin
                $url/raw/$_commit/boot/fixup.dat
                $url/raw/$_commit/boot/start.elf
                $url/raw/$_commit/boot/fixup_x.dat
                $url/raw/$_commit/boot/start_x.elf"
subpackages="$pkgname-x:bootloader_x"

package() {
        cd "$srcdir"
        mkdir -p "$pkgdir"/boot
        cp bootcode.bin fixup.dat start.elf "$pkgdir"/boot/
}

bootloader_x() {
        pkgdesc="Extra codecs for the Raspberry Pi"
        depends="$pkgname"
        cd "$srcdir"
        mkdir -p "$subpkgdir"/boot
        cp start_x.elf fixup_x.dat "$subpkgdir"/boot/
}

sha512sums="c72ca625e16e0a11524f77b5b7a764fec9c93178d4c8fe5ba60225dcfacd3fe5c363542c452829f9e5458282cbe607ca3027c80f9d9599523eb9a3443976b8db  bootcode.bin
7e51fc705abf5606205963028abf20324c153a2db8ed63e48ad4ef7fe42bf5cc30f41a49e361b222ef6cbf29a4c8103063f40e2397abfb37911c87f52399b330  fixup.dat
ddb0933ca1db3037b0c9f0b9d718605f039063cf140518c6bc2c10e54c75285f812775207829a226822a3e076e4f3f540bd51520ad4166aa99aedf2a1b240fe3  start.elf
e43857bddd1e033645b4da6cf8cff0169db27112d0c60a778734c2133f6a61a780952045e6a02206f36d97d70e0dafa18b83818cd49e0cafd524f72768b5a5ff  fixup_x.dat
b8324d841ca3a27ad788c10b2513666341f0c7d8d0b58ca30bf752ad87715bbf19561796fd2a3b7436b4a11d973506d5addc238ffff084a07264d6a2b5336631  start_x.elf"

and to make pmos boot on pi 3 plus, we may also need the devices tree files bcm2710-rpi-3-b-plus.dtb, the new model also have some other upgrade, to make it's eth0 work, we have to enable CONFIG_USB_LAN78XX when compile kernel.

with new rpi kernel 4.14.39 links here, I can boot pmos on 3b+ now, the vc4 also works, but wifi not work, details describe in this comment: #1507 (comment)

Maybe we can add a new post upgrade scripts for two kernel, the content same as device-raspberry-pi-kernel-rpi.post-install or device-raspberry-pi-kernel-rpi2.post-install, then it can auto copy the latest devices tree files to boot partition after upgrade kernel.

I don't have a rpi1, actually there is no rpi1, first generation is A+ (256MB memory), B+(512 memory)
now I just have two rpi3, one zero w, and one rpi 3b+, but the B+ is basically same as zero, or zero w, just zero w come with built-in wifi and bluetooth, so if pmos can run on zero w, then it should able to run B+, as for A+, it's kind of heavy for it to run it, but should also work.

@drebrez

This comment has been minimized.

Copy link
Member Author

commented May 25, 2018

@yangxuan8282 I've tested omxplayer with this udev rule
SUBSYSTEM=="vchiq", GROUP="video", MODE="0660"
and it works fine.
In your udev rule you also added input, mouse, mice...
I've probably avoided some error adding the user to the input group.
For that we can add the input group here:

install_user_groups = ["wheel", "video", "audio"]

@ollieparanoid it's ok for you?

@yangxuan8282

This comment has been minimized.

Copy link
Contributor

commented May 26, 2018

@drebrez
that udev rules was taken from other distros, should be archlinux arm
since your udev rules have been tested, so use it should be ok, the 0660 should enough for video player, but for some other applications like sdl program or game emulator I'm not sure, but we can modified when got related issues
so I think you can just add your udev rules to device packages now

BTW, I have build new linux-rpi kernel, with vc4 enable, still need test, would you mind try it?
https://github.com/yangxuan8282/rpi-aports/blob/master/linux-rpi/APKBUILD
here is the apks: https://github.com/yangxuan8282/rpi-aports/blob/master/apks/linux-rpi2-4.14.39-r0.apk

and maybe we should add a triggers in APKBUILD of device-raspberry-pi, the content same as device-raspberry-pi-kernel-rpi.post-install or device-raspberry-pi-kernel-rpi2.post-install:

triggers="$subpackages.trigger=/boot:/usr/share/kernel/*"

device-raspberry-pi-kernel-rpi.trigger

#!/bin/sh

kernver=$(cat /usr/share/kernel/rpi/kernel.release)
cd /usr/lib/linux-${kernver}/
find . -type f -regex ".*\.dtbo\?$" -exec install -Dm644 {} /boot/{} \;

device-raspberry-pi-kernel-rpi2.trigger

#!/bin/sh

kernver=$(cat /usr/share/kernel/rpi2/kernel.release)
cd /usr/lib/linux-${kernver}/
find . -type f -regex ".*\.dtbo\?$" -exec install -Dm644 {} /boot/{} \;

this will auto copy the new dtb to /boot, or add a $pkgname.post-upgrade scripts, I'm not sure

@ollieparanoid

This comment has been minimized.

Copy link
Member

commented May 26, 2018

@drebrez: yeah, adding input makes sense to me!

@yangxuan8282: I don't understand what you mean with the udev rules. Don't we have exactly these rules already?

but the B+ is basically same as zero, or zero w, just zero w come with built-in wifi and bluetooth, so if pmos can run on zero w, then it should able to run B+, as for A+, it's kind of heavy for it to run it, but should also work.

That sounds reasonable! I guess then we don't necessarily need to wait for a test with the Raspberry Pi 1 Model B.

drebrez added some commits May 16, 2018

@ollieparanoid ollieparanoid force-pushed the device/raspberry-pi branch from 08ad235 to 7effcff May 28, 2018

@drebrez

This comment has been minimized.

Copy link
Member Author

commented May 29, 2018

@yangxuan8282 unfortunately I don't have much time lately to test the kernel you packaged.
I've added the udev rule to fix the permission of vchiq and added the default user to the input group so that the omxplayer works.
I think we can close this PR and then create a new PR with the new linux-rpi kernel you packaged and maybe also with the updated raspberrypi-bootloader.
The wiki still needs to be updated a little bit with what works and what not.
@ollieparanoid

@ollieparanoid

This comment has been minimized.

Copy link
Member

commented May 29, 2018

What do you mean with close, not merging it?

I thought this PR is pretty much ready to merge as it is, because it makes the basic pi installation possible. And that we would make future improvements (e.g. change the kernel) on top of that. What do you think, are there any reasons against merging it now?

@drebrez

This comment has been minimized.

Copy link
Member Author

commented May 29, 2018

@ollieparanoid ollieparanoid merged commit dfde37c into master May 29, 2018

3 checks passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
continuous-integration/travis-ci/push The Travis CI build passed
Details
coverage/coveralls Coverage increased (+0.007%) to 78.629%
Details

@ollieparanoid ollieparanoid deleted the device/raspberry-pi branch May 29, 2018

@ollieparanoid ollieparanoid referenced this pull request Jun 14, 2018

Closed

Testing the new Raspberry Pi kernel update #1567

4 of 5 tasks complete
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.