<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jan 19, 2018 at 10:17 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Hi Michael</div><span class=""><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 dir="ltr">Thanks for the patches. The modification to debian/kernel/postinst.d/ra<wbr>spi3-firmware could be simplified, I think. Why not just:<div><br></div><div>[ -e "${dtb_path}/bcm2836-rpi-2-b.d<wbr>tb"] && cp ${dtb_path}/bcm2836-rpi-2-b.dt<wbr>b /boot/firmware/bcm2709-rpi-2-b<wbr>.dtb</div><div><div>[ -e "${dtb_path}/bcm2837-rpi-3-b.d<wbr>tb"] && cp ${dtb_path}/bcm2837-rpi-3-b.dt<wbr>b /boot/firmware/bcm2710-rpi-3-b<wbr>.dtb</div></div></div></blockquote><div><br></div></span><div>This would indeed simplify the script. However, with my modification I tried to keep the same logic as before:</div><div><ol><li>First we check that all required pieces are in place (kernel, initial ramdisk, device tree binary or binaries).</li><li>Only copy the required pieces to /boot/firmware if everything is available, otherwise print a message and do a exit 0.<br></li></ol><div>Your proposed modification would silently ignore if the device tree binaries could not be retrieved (e.g. because they are missing, were renamed or moved to another location).</div></div><div><br></div><div>We could then even end up with an inconsistent system (new kernel, device tree binaries from a previous kernel installation).</div></div></div></div></blockquote><div><br></div><div>I’d argue that if users move their device tree files around, they know better what they’re doing and we shouldn’t interfere :)</div><div><br></div><div>Let’s try the simplified logic.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>I even though about doing an exit 1 instead of an exit 0 but I think the exit 0 is supposed to cover the case if the raspi3-firmware package gets installed prior to the kernel package.</div><span class=""><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 dir="ltr"><div>Also, can you explain the following syntax?<br></div><div><br></div><div>: chroot detected - skip mount point check<br></div></div></blockquote><div><br></div></span><div>The ":" is a "no operation". The stuff behind it is just comment. A logically equivalent statement would be:</div><div>true # chroot detected - skip mount point check<br></div></div></div></div></blockquote><div><br></div><div>Thanks for the explanation. Could you change it to the syntax using #? It’s more well-known.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><span class=""><div><br></div><div><br></div><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"><div></div><div>Can you outline whether there’s a downside to setting cma=64M? </div></div></blockquote><div><br></div></span><div>On arm64 this has no impact at all since CONFIG_CMA_SIZE_MBYTES is anyway set to 64. On armmp-lpae CONFIG_CMA_SIZE_<wbr>MBYTES is set to 16. So this will reduce the generally available RAM a bit but it allows the vc4 driver to initialize the GPU.</div></div></div></div></blockquote><div><br></div><div>Ah, if the value matches arm64’s default, that’s good enough for me.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><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 dir="ltr"><div>Are the 64M then reserved for graphics, and can no longer be used as general purpose memory?<br></div></div></blockquote><div><br></div></span><div>Unfortunately I am not familiar with the details. The kernel documentation looks like this:</div><div><br></div></div></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div class="gmail_extra"><div class="gmail_quote"><div><div>CONFIG_CMA:</div></div></div></div><div class="gmail_extra"><div class="gmail_quote"><div><div><br></div></div></div></div><div class="gmail_extra"><div class="gmail_quote"><div><div>This enables the Contiguous Memory Allocator which allows other</div></div></div></div><div class="gmail_extra"><div class="gmail_quote"><div><div>subsystems to allocate big physically-contiguous blocks of memory.</div></div></div></div><div class="gmail_extra"><div class="gmail_quote"><div><div>CMA reserves a region of memory and allows only movable pages to</div></div></div></div><div class="gmail_extra"><div class="gmail_quote"><div><div>be allocated from it. This way, the kernel can use the memory for</div></div></div></div><div class="gmail_extra"><div class="gmail_quote"><div><div>pagecache and when a subsystem requests for contiguous area, the</div></div></div></div><div class="gmail_extra"><div class="gmail_quote"><div><div>allocated pages are migrated away to serve the contiguous request.</div></div></div></div></blockquote><br><div class="gmail_extra"><div class="gmail_quote"><div>Therefore I guess that the access to the reserved area is restricted and can not be fully used for general purpose stuff.</div><span class=""><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 dir="ltr"><div></div><div>What’s the dosfstools dependency required for?<br></div></div></blockquote><div><br></div></span><div>dosfstools contains fsck.vfat. If this binary is missing, the script debian/initramfs-tools/<wbr>hooks/raspi3-firmware-fsck will fail.</div></div></div></div></blockquote><div><br>Can you mention this detail in the commit message please?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>Please let me know if I should do changes to my patches. I can then re-test the stuff.</div><div><br></div><div>Best regards</div><span class="HOEnZb"><font color="#888888"><div>Matthias </div><div><br></div><div><br></div></font></span></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></div>