<div dir="ltr">Thanks for the patches. The modification to debian/kernel/postinst.d/raspi3-firmware could be simplified, I think. Why not just:<div><br></div><div>[ -e "${dtb_path}/bcm2836-rpi-2-b.dtb"] && cp ${dtb_path}/bcm2836-rpi-2-b.dtb /boot/firmware/bcm2709-rpi-2-b.dtb</div><div><div>[ -e "${dtb_path}/bcm2837-rpi-3-b.dtb"] && cp ${dtb_path}/bcm2837-rpi-3-b.dtb /boot/firmware/bcm2710-rpi-3-b.dtb</div></div><div><br></div><div>Also, can you explain the following syntax?</div><div><br></div><div>: chroot detected - skip mount point check<br></div><div><br></div><div>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?</div><div><br></div><div>What’s the dosfstools dependency required for?</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 18, 2018 at 10:37 PM, Matthias Luescher <span dir="ltr"><<a href="mailto:lueschem@gmail.com" target="_blank">lueschem@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Michael<div><br></div><div>I finally got a Raspberry Pi 2 B to validate my changes!</div><div><br></div><div>I attached all my modifications as patches to this e-mail.</div><div><br></div><div>If you prefer GitHub, you can also find the source code here: <a href="https://github.com/lueschem/raspi3-firmware/tree/raspi3_firmware_tweaks" target="_blank">https://github.com/<wbr>lueschem/raspi3-firmware/tree/<wbr>raspi3_firmware_tweaks</a></div><div><br></div><div>I successfully tested the following scenarios using Debian stretch:</div><div><br></div><div>- arm64 on Raspberry Pi 3 B, kernel package linux-image-4.14.0-0.<wbr>bpo.3-arm64</div><div>- armhf on Raspberry Pi 3 B, kernel package linux-image-4.14.0-0.<wbr>bpo.3-armmp-lpae</div><div>- armhf on Raspberry Pi 2 B, kernel package linux-image-4.14.0-0.<wbr>bpo.3-armmp-lpae</div><div><br></div><div>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.</div><div><br></div><div>It would be great if you could include this changes in your package!</div><div><br></div><div>Many thanks and best regards</div><span class="HOEnZb"><font color="#888888"><div>Matthias</div></font></span><div><div class="h5"><div><br></div><div><br></div><div><br></div><div class="gmail_extra"><br><div class="gmail_quote">2018-01-15 23:04 GMT+01:00 Matthias Luescher <span dir="ltr"><<a href="mailto:lueschem@gmail.com" target="_blank">lueschem@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi Michael<br><div class="gmail_extra"><br><div class="gmail_quote"><span class="m_-4268021190272811543gmail-"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Thanks for checking. Both changes sound good, so feel free to go ahead. Thanks in advance!</div></blockquote><div><br></div></span><div>Great - my working copy is here:</div><div><a href="https://github.com/lueschem/raspi3-firmware/commits/raspi3_firmware_tweaks" target="_blank">https://github.com/lueschem/ra<wbr>spi3-firmware/commits/raspi3_<wbr>firmware_tweaks</a><br></div><div><br></div><div>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.</div><div><br></div><div>Best regards</div><span class="m_-4268021190272811543gmail-HOEnZb"><font color="#888888"><div>Matthias</div></font></span><div><div class="m_-4268021190272811543gmail-h5"><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail_extra"><div><div class="m_-4268021190272811543gmail-m_-2377258463050439662gmail-h5"><br><div class="gmail_quote">On Fri, Jan 12, 2018 at 9:57 AM, Matthias Luescher <span dir="ltr"><<a href="mailto:lueschem@gmail.com" target="_blank">lueschem@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi Michael<div><br></div><div>Before I start to invest more time I would like to know your opinion whether I should go on:</div><div><br></div><div>For the raspi3-firmware package I have a two suggestions that I could try to implement:</div><div><br></div><div><b>container awareness:</b></div><div><br></div><div>The script raspi3-firmware.postinst does not complain about missing mount points when running in a chroot:</div><div><br></div><div><div>if ! ischroot; then</div><div> if ! mountpoint -q /boot/firmware; then</div><div> echo "raspi3-firmware: missing /boot/firmware, did you forget to mount it?" >&2</div><div> exit 1</div><div> fi</div><div>fi</div></div><div><br></div><div>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.</div><div><br></div><div><b>device tree handling:</b></div><div><br></div><div>According to</div><div><a href="https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=848101" target="_blank">https://bugs.debian.org/cgi-bi<wbr>n/bugreport.cgi?bug=848101</a><br></div><div>people also use raspi3-firmware on a Raspberry Pi 2.</div><div><br></div><div>The use cases I see are:</div><div>1) linux-image-armmp-lpae (32bit) on Raspi 2 B</div><div>2) linux-image-armmp-lpae (32bit) on Raspi 3 B</div><div>3) linux-image-arm64 (64bit) on Raspi 3 B</div><div><br></div><div>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:</div><div><br></div><div># Detect appropriate .dtb</div><div>arch=$(dpkg --print-architecture)</div><div>case ${arch} in</div><div> armhf)</div><div> dtb=bcm2836-rpi-2-b.dtb</div><div> ;;</div><div> arm64)</div><div> dtb=bcm2837-rpi-3-b.dtb</div><div> ;;</div><div>esac</div><div>...</div><div><br></div><div>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).</div><div><br></div><div>What do you think about the above changes? Shall I start to dig deeper?</div><div><br></div><div>Best regards</div><span class="m_-4268021190272811543gmail-m_-2377258463050439662gmail-m_4459398947213776785HOEnZb"><font color="#888888"><div>Matthias</div></font></span></div>
</blockquote></div><br><br clear="all"><div><br></div></div></div><span class="m_-4268021190272811543gmail-m_-2377258463050439662gmail-HOEnZb"><font color="#888888">-- <br><div class="m_-4268021190272811543gmail-m_-2377258463050439662gmail-m_4459398947213776785gmail_signature">Best regards,<br>Michael</div>
</font></span></div>
</blockquote></div></div></div><br></div></div>
</blockquote></div><br></div></div></div></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Best regards,<br>Michael</div>
</div>