On 13/03/2019 22:14, Stefan Wahren wrote:
Hi,
recently i stumbled upon this issue [1] in Arch Linux. The obvious issue is the difference of the DTB naming between U-Boot und Linux.
From my point of view is that the Compute Module is only a SoM and not runnable standalone. So the name bcm2837-rpi-cm3.dtb is only half of the truth. So i decided to append the carrier board (IO board 3 in this case) to the dtb name like for NXP i.MX6UL SoM. But there are many more carrier boards out there.
The problem is that the Compute Module don't have a chance to detect the connected carrier.
A pragmatic approach would be to rename the dtb entry to bcm2837-rpi-cm3-io3.dtb which is suitable to boot in most cases.
Or we keep the name in u-boot and it's up to the user / distributor to choose the right DTB.
Any ideas?
I don't have a good answer to that. On the one hand we should stick to the kernel device tree blob. There does ony the IO board 3 exist there at the moment. So most probably if anyone wants to boot something different he will need his own DTB, so we could expect that he is OK with fixing the boot process to load his DTB.
But that only holds until another DTB for an extension board got added to the kernel. Apart we silently boot any board with a compute module with a DTB that's not correct. This might be dangerous depending on the layout of the carrier board.
So I think it is reasonable to leave it as it is and let the distributor decide. At least that makes it explicit that the user/distributor should think twice before adding any DTB file. We could rename the dtb to something like bcm2835-rpi-cm-unknown-board.dtb
We could then add a Kconfig option to overwrite the model->fdtfile entry in get_board_rev.
Any opinions?
Regards, Matthias
Best regards Stefan
[1] - https://archlinuxarm.org/forum/viewtopic.php?f=65&t=13486