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

[Michael Stapelberg]

On Fri, Jan 19, 2018 at 10:17 AM, Matthias Luescher <lueschem at gmail.com>
wrote:

> Hi Michael
>
>
>> 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
>>
>
> This would indeed simplify the script. However, with my modification I
> tried to keep the same logic as before:
>
>    1. First we check that all required pieces are in place (kernel,
>    initial ramdisk, device tree binary or binaries).
>    2. Only copy the required pieces to /boot/firmware if everything is
>    available, otherwise print a message and do a exit 0.
>
> 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).
>
> We could then even end up with an inconsistent system (new kernel, device
> tree binaries from a previous kernel installation).
>

I’d argue that if users move their device tree files around, they know
better what they’re doing and we shouldn’t interfere :)

Let’s try the simplified logic.


>
> 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.
>
>
>> Also, can you explain the following syntax?
>>
>> : chroot detected - skip mount point check
>>
>
> The ":" is a "no operation". The stuff behind it is just comment. A
> logically equivalent statement would be:
> true # chroot detected - skip mount point check
>

Thanks for the explanation. Could you change it to the syntax using #? It’s
more well-known.


>
>
> Can you outline whether there’s a downside to setting cma=64M?
>>
>
> On arm64 this has no impact at all since CONFIG_CMA_SIZE_MBYTES is anyway
> set to 64. On armmp-lpae CONFIG_CMA_SIZE_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.
>

Ah, if the value matches arm64’s default, that’s good enough for me.


>
>
>> Are the 64M then reserved for graphics, and can no longer be used as
>> general purpose memory?
>>
>
> Unfortunately I am not familiar with the details. The kernel documentation
> looks like this:
>
> CONFIG_CMA:
>
> This enables the Contiguous Memory Allocator which allows other
> subsystems to allocate big physically-contiguous blocks of memory.
> CMA reserves a region of memory and allows only movable pages to
> be allocated from it. This way, the kernel can use the memory for
> pagecache and when a subsystem requests for contiguous area, the
> allocated pages are migrated away to serve the contiguous request.
>
>
> Therefore I guess that the access to the reserved area is restricted and
> can not be fully used for general purpose stuff.
>
>
>> What’s the dosfstools dependency required for?
>>
>
> dosfstools contains fsck.vfat. If this binary is missing, the
> script debian/initramfs-tools/hooks/raspi3-firmware-fsck will fail.
>

Can you mention this detail in the commit message please?


>
> Please let me know if I should do changes to my patches. I can then
> re-test the stuff.
>
> Best regards
> Matthias
>
>
>


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