[Pkg-raspi-maintainers] raspi3-firmware: container awareness and device tree handling

[Michael Stapelberg]

Thanks for the patches. The modification
to debian/kernel/postinst.d/raspi3-firmware could be simplified, I think.
Why not just:

[ -e "${dtb_path}/bcm2836-rpi-2-b.dtb"] && cp
${dtb_path}/bcm2836-rpi-2-b.dtb /boot/firmware/bcm2709-rpi-2-b.dtb
[ -e "${dtb_path}/bcm2837-rpi-3-b.dtb"] && cp
${dtb_path}/bcm2837-rpi-3-b.dtb /boot/firmware/bcm2710-rpi-3-b.dtb

Also, can you explain the following syntax?

: chroot detected - skip mount point check

Can you outline whether there’s a downside to setting cma=64M? Are the 64M
then reserved for graphics, and can no longer be used as general purpose
memory?

What’s the dosfstools dependency required for?

On Thu, Jan 18, 2018 at 10:37 PM, Matthias Luescher <lueschem at gmail.com>
wrote:

> Hi Michael
>
> I finally got a Raspberry Pi 2 B to validate my changes!
>
> I attached all my modifications as patches to this e-mail.
>
> If you prefer GitHub, you can also find the source code here:
> https://github.com/lueschem/raspi3-firmware/tree/raspi3_firmware_tweaks
>
> I successfully tested the following scenarios using Debian stretch:
>
> - arm64 on Raspberry Pi 3 B, kernel package linux-image-4.14.0-0.
> bpo.3-arm64
> - armhf on Raspberry Pi 3 B, kernel package linux-image-4.14.0-0.
> bpo.3-armmp-lpae
> - armhf on Raspberry Pi 2 B, kernel package linux-image-4.14.0-0.
> bpo.3-armmp-lpae
>
> When using armhf, the same image can be dispatched to a Pi 2 B and a Pi 3
> B. The bootloader seems to choose the right device tree binary.
>
> It would be great if you could include this changes in your package!
>
> Many thanks and best regards
> Matthias
>
>
>
>
> 2018-01-15 23:04 GMT+01:00 Matthias Luescher <lueschem at gmail.com>:
>
>> Hi Michael
>>
>> Thanks for checking. Both changes sound good, so feel free to go ahead.
>>> Thanks in advance!
>>>
>>
>> Great - my working copy is here:
>> https://github.com/lueschem/raspi3-firmware/commits/raspi3_
>> firmware_tweaks
>>
>> I have now ordered a Raspberry Pi 2 B to validate the changes. I will let
>> you know when I have finished the modifications and the testing.
>>
>> Best regards
>> Matthias
>>
>>
>>
>>>
>>> On Fri, Jan 12, 2018 at 9:57 AM, Matthias Luescher <lueschem at gmail.com>
>>> wrote:
>>>
>>>> Hi Michael
>>>>
>>>> Before I start to invest more time I would like to know your opinion
>>>> whether I should go on:
>>>>
>>>> For the raspi3-firmware package I have a two suggestions that I could
>>>> try to implement:
>>>>
>>>> *container awareness:*
>>>>
>>>> The script raspi3-firmware.postinst does not complain about missing
>>>> mount points when running in a chroot:
>>>>
>>>> if ! ischroot; then
>>>>   if ! mountpoint -q /boot/firmware; then
>>>>     echo "raspi3-firmware: missing /boot/firmware, did you forget to
>>>> mount it?" >&2
>>>>     exit 1
>>>>   fi
>>>> fi
>>>>
>>>> Would it be ok if I also detect containers there and threat it the same
>>>> as a chroot? I personally use a LXC container to build the image and I see
>>>> more and more people that take systemd-nspawn instead of a chroot.
>>>>
>>>> *device tree handling:*
>>>>
>>>> According to
>>>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=848101
>>>> people also use raspi3-firmware on a Raspberry Pi 2.
>>>>
>>>> The use cases I see are:
>>>> 1) linux-image-armmp-lpae (32bit) on Raspi 2 B
>>>> 2) linux-image-armmp-lpae (32bit) on Raspi 3 B
>>>> 3) linux-image-arm64 (64bit) on Raspi 3 B
>>>>
>>>> However, it looks like only use case 1) and 3) are supported due to
>>>> hard coded values that make it into /boot/firmware/config.txt:
>>>>
>>>> # Detect appropriate .dtb
>>>> arch=$(dpkg --print-architecture)
>>>> case ${arch} in
>>>>   armhf)
>>>>     dtb=bcm2836-rpi-2-b.dtb
>>>>     ;;
>>>>   arm64)
>>>>     dtb=bcm2837-rpi-3-b.dtb
>>>>     ;;
>>>> esac
>>>> ...
>>>>
>>>> After some reverse engineering of the official raspi image I found out
>>>> that we could omit the device_tree=... setting in the config.txt file.
>>>> Instead we would just have to copy multiple dtbs to the /boot/firmware
>>>> folder and rename them so that the bootloader automatically chooses the
>>>> right one. This might then also enable use case 2).
>>>>
>>>> What do you think about the above changes? Shall I start to dig deeper?
>>>>
>>>> Best regards
>>>> Matthias
>>>>
>>>
>>>
>>>
>>> --
>>> Best regards,
>>> Michael
>>>
>>
>>
>


-- 
Best regards,
Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-raspi-maintainers/attachments/20180118/d8ad6674/attachment.html>