Lines Matching +full:arm +full:- +full:platform
1 .. SPDX-License-Identifier: GPL-2.0
44 ----------
56 In 2005, when PowerPC Linux began a major cleanup and to merge 32-bit
57 and 64-bit support, the decision was made to require DT support on all
61 blob without requiring a real Open Firmware implementation. U-Boot,
66 existing non-DT aware firmware.
70 architectures (arm, microblaze, mips, powerpc, sparc, and x86) and 1
74 -------------
79 -------------------
88 per-machine hard coded selections.
90 Ideally, data driven platform setup should result in less code
96 1) platform identification,
100 2.2 Platform Identification
101 ---------------------------
103 specific machine. In a perfect world, the specific platform shouldn't
104 matter to the kernel because all platform details would be described
108 machine-specific fixups.
112 CPU or SoC. On ARM for example, setup_arch() in
113 arch/arm/kernel/setup.c will call setup_machine_fdt() in
114 arch/arm/kernel/devtree.c which searches through the machine_desc
119 arch/arm/include/asm/mach/arch.h if you're curious).
127 compatible = "ti,omap3-beagleboard", "ti,omap3450", "ti,omap3";
128 compatible = "ti,omap3-beagleboard-xm", "ti,omap3450", "ti,omap3";
130 Where "ti,omap3-beagleboard-xm" specifies the exact model, it also
150 Again on ARM, for each machine_desc, the kernel looks to see if
175 matches on "ti,omap3-beagleboard".
184 -------------------------
195 initrd-start = <0xc8000000>;
196 initrd-end = <0xc8200000>;
199 The bootargs property contains the kernel arguments, and the initrd-*
201 initrd-end is the first address after the initrd image, so this doesn't
204 platform-specific configuration data.
216 On ARM, the function setup_machine_fdt() is responsible for early
221 ---------------------
226 This is also when machine-specific setup hooks will get called, like
228 on ARM. The remainder of this section uses examples from the ARM
232 As can be guessed by the names, .init_early() is used for any machine-
238 get additional data about the platform.
242 data about the platform. Historically this has been implemented on
245 registering it en-masse in .init_machine(). When DT is used, then
246 instead of hard coding static devices for each platform, the list of
254 later). While there is no 'platform device' terminology for the DT,
255 platform devices roughly correspond to device nodes at the root of the
263 #address-cells = <1>;
264 #size-cells = <1>;
265 interrupt-parent = <&intc>;
276 compatible = "nvidia,tegra20-soc", "simple-bus";
277 #address-cells = <1>;
278 #size-cells = <1>;
281 intc: interrupt-controller@50041000 {
282 compatible = "nvidia,tegra20-gic";
283 interrupt-controller;
284 #interrupt-cells = <1>;
289 compatible = "nvidia,tegra20-uart";
295 compatible = "nvidia,tegra20-i2s";
302 compatible = "nvidia,tegra20-i2c";
303 #address-cells = <1>;
304 #size-cells = <0>;
317 compatible = "nvidia,harmony-sound";
318 i2s-controller = <&i2s1>;
319 i2s-codec = <&wm8903>;
369 as platform devices too? For Linux DT support, the generic behaviour
378 and register platform_devices for /soc/interrupt-controller, /soc/serial,
395 "simple-bus" is defined in the Devicetree Specification as a property
397 could be written to just assume simple-bus compatible nodes will
404 ------------------------
406 ARM Primecells are a certain kind of device attached to the ARM AMBA
418 be too invasive. If a node is compatible with "arm,amba-primecell", then