Lines Matching +full:kernel +full:- +full:family
1 .. SPDX-License-Identifier: GPL-2.0
7 Paul Mundt <lethal@linux-sh.org>
18 of the board-specific code (with the exception of stboards) ended up
19 in arch/sh/kernel/ directly, with board-specific headers ending up in
20 include/asm-sh/. For the new kernel, things are broken out by board type,
24 Board-specific code::
27 |-- arch
28 | `-- sh
29 | `-- boards
30 | |-- adx
31 | | `-- board-specific files
32 | |-- bigsur
33 | | `-- board-specific files
37 `-- include
38 `-- asm-sh
39 |-- adx
40 | `-- board-specific headers
41 |-- bigsur
42 | `-- board-specific headers
49 `-- arch
50 `-- sh
51 `-- cchips
52 `-- hd6446x
53 `-- hd64461
54 `-- cchip-specific files
57 board-specific headers. Thus, include/asm-sh/hd64461 is home to all of the
58 hd64461-specific headers.
60 Finally, CPU family support is also abstracted::
63 |-- arch
64 | `-- sh
65 | |-- kernel
66 | | `-- cpu
67 | | |-- sh2
68 | | | `-- SH-2 generic files
69 | | |-- sh3
70 | | | `-- SH-3 generic files
71 | | `-- sh4
72 | | `-- SH-4 generic files
73 | `-- mm
74 | `-- This is also broken out per CPU family, so each family can
77 `-- include
78 `-- asm-sh
79 |-- cpu-sh2
80 | `-- SH-2 specific headers
81 |-- cpu-sh3
82 | `-- SH-3 specific headers
83 `-- cpu-sh4
84 `-- SH-4 specific headers
87 need to be dealt with by the CPU family specific code.
93 isolated, or whether it will be part of a family of boards that can mostly
94 share the same board-specific code with minor differences.
99 it makes more sense to have a common top-level arch/sh/boards/ directory
100 and then populate that with sub-directories for each member of the family.
104 should also add a directory in include/asm-sh for headers localized to this
108 a family, the build system has ways of dealing with this (via incdir-y
109 overloading), and you can feel free to name the directory after the family
113 arch/sh/boards and the include/asm-sh/ hierarchy. In order to better
120 * arch/sh/boards/vapor/setup.c - Setup code for imaginary board
138 /* Start-up imaginary PCI ... */
150 - I/O functions to IO memory (inb etc) and PCI/main memory (readb etc).
151 - I/O mapping functions (ioport_map, ioport_unmap, etc).
152 - a 'heartbeat' function.
153 - PCI and IRQ initialization routines.
154 - Consistent allocators (for boards that need special allocators,
155 particularly for allocating out of some board-specific SRAM for DMA
159 consult include/asm-sh/machvec.h for the current state of the machvec.
161 The kernel will automatically wrap in generic routines for undefined function
169 If the board-specific definitions are quite minimalistic, as is the case for
170 the vast majority of boards, simply having a single board-specific header is
173 - add a new file include/asm-sh/vapor.h which contains prototypes for
184 somewhere in the board-specific header. Any boards being ported that still
187 - Add machine vector definitions to the board's setup.c. At a bare minimum,
195 - finally add a file arch/sh/boards/vapor/io.c, which contains definitions of
202 board-specific code is in place, it's time to look at how to get the
217 machdir-y entry in order to be built. This entry needs to be the name of
219 sub-directory (in which case, all parent directories below arch/sh/boards/
222 machdir-$(CONFIG_SH_VAPOR) += vapor
226 Next, the build system assumes that your include/asm-sh directory will also
228 boards belonging to a common family), then the directory name needs to be
229 implicitly appended to incdir-y. The existing code manages this for the
233 This is done by adding an entry to the end of the arch/sh/tools/mach-types
241 return -ENODEV;
244 lowercase, regardless of the fact that the mach-types entries are all
262 zImage Compressed kernel image (arch/sh/boot/zImage)
272 $ make ARCH=sh CROSS_COMPILE=sh4-linux- vapor_defconfig vmlinux
276 and start you on your way to having a functional kernel for your new