Lines Matching refs:board

80 hardware configuration from the board and device driver support in the
82 it allows board and device support to become data driven; to make
120 successor, the BeagleBoard xM board might look like, respectively:
128 specific (exact board) to least specific (SoC family).
131 compatibility with the original Beagle board.  However, one should be
132 cautioned about doing so at the board level since there is typically a
133 high level of change from one board to another, even within the same
135 board claims to be compatible with another.  For the top level, it is
136 better to err on the side of caution and not claim one board is
138 board is a carrier for another, such as a CPU module attached to a
139 carrier board.
156 invariably there will be some exceptions where a specific board will
159 troublesome board(s) in generic setup code, but doing so very quickly
166 generic board support can claim compatibility with "ti,omap3" or
213 that supports the board.
217 After the board has been identified, and after the early configuration data
239 platform_devices, and other data in the board support .c file, and
254 device tree for the NVIDIA Tegra board.
318 At .init_machine() time, Tegra board support code will need to look at
328 because I'm familiar with the board design, but how does the kernel
353 Linux board support code calls of_platform_populate(NULL, NULL, NULL, NULL)
358 table (yet).  For a board that only needs to register devices,
371 children.  The board support code would allocate and register an SoC
394 board support code can always override the default behaviour.