On Mon, Nov 5, 2012 at 2:40 PM, Grant Likely grant.lik...@secretlab.ca wrote:
Jane is building custom BeagleBone expansion boards called 'capes'. She
can boot the system with a stock BeagleBoard device tree, but additional
data is needed before a cape can be used. She could replace the FDT file
used by U-Boot with one that contains the extra data, but she uses the
same Linux system image regardless of the cape, and it is inconvenient
to have to select a different device tree at boot time depending on the
cape.
What's wrong with having the boot loader detect the presence of the
Cape and update the device tree accordingly? We do this all the time
in U-Boot. Doing stuff like reading EEPROMs and testing for the
presence of hardware is easier in U-Boot than in Linux.
For configurations that can be determined by the boot loader, I'm not
sure overlays are practical.
Nigel is building a real-time video processing system around a MIPS SoC
and a Virtex FPGA. Video data is streamed through the FPGA for post
processing operations like motion tracking or compression. The FPGA is
configured via the SPI bus, and is also connected to GPIO lines and the
memory mapped peripheral bus. Nigel has designed several FPGA
configurations for different video processing tasks. The user will
choose which configuration to load which can even be reprogrammed at
runtime to switch tasks.
Now this, on the other hand, makes more sense. If the hardware
configuration is literally user-configurable, then okay. However, I'm
not sure I see the need to update the device tree. The device tree is
generally for hardware that cannot be discovered/probed by the device
driver. If we're loading a configuration from user space, doesn't the
driver already know what the hardware's capabilities are, since it's
the one doing the uploading of a new FPGA code? Why not skip the
device tree update and just tell the driver what the new capabilities
are?
--
Timur Tabi
Linux kernel developer at Freescale
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
