Lines Matching +full:long +full:- +full:ram +full:- +full:code
1 .. SPDX-License-Identifier: GPL-2.0
20 so that the operating system doesn't need to hard code details of the
34 maximize use of existing support code, but since property and node
44 ----------
53 the Linux support for those architectures has for a long time used the
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.
74 -------------
79 -------------------
88 per-machine hard coded selections.
90 Ideally, data driven platform setup should result in less code
101 ---------------------------
108 machine-specific fixups.
111 kernel will instead select setup code based on the machine's core
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
162 require special setup code that is not useful in the generic case.
164 troublesome board(s) in generic setup code, but doing so very quickly
173 that required special workaround code during early boot, then a new
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.
206 During early boot, the architecture setup code calls of_scan_flat_dt()
208 data before paging is setup. The of_scan_flat_dt() code scans through
214 location of usable RAM.
221 ---------------------
226 This is also when machine-specific setup hooks will get called, like
232 As can be guessed by the names, .init_early() is used for any machine-
245 registering it en-masse in .init_machine(). When DT is used, then
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>;
323 At .init_machine() time, Tegra board support code will need to look at
358 Linux board support code calls of_platform_populate(NULL, NULL, NULL, NULL)
376 children. The board support code would allocate and register an SoC
378 and register platform_devices for /soc/interrupt-controller, /soc/serial,
383 device tree support code reflects that and makes the above example
386 will also get its child nodes registered. In the Tegra case, the code
395 "simple-bus" is defined in the Devicetree Specification as a property
396 meaning a simple memory mapped bus, so the of_platform_populate() code
397 could be written to just assume simple-bus compatible nodes will
399 board support code can always override the default behaviour.
404 ------------------------