1 S3C24XX ARM Linux Overview
2 ==========================
9 The Samsung S3C24XX range of ARM9 System-on-Chip CPUs are supported
10 by the 's3c2410' architecture of ARM Linux. Currently the S3C2410,
11 S3C2440 and S3C2442 devices are supported.
13 Support for the S3C2400 series is in progress.
15 Support for the S3C2412 and S3C2413 CPUs is being merged.
21 A generic S3C2410 configuration is provided, and can be used as the
22 default by `make s3c2410_defconfig`. This configuration has support
23 for all the machines, and the commonly used features on them.
25 Certain machines may have their own default configurations as well,
26 please check the machine specific documentation.
32 The currently supported machines are as follows:
34 Simtec Electronics EB2410ITX (BAST)
36 A general purpose development board, see EB2410ITX.txt for further
39 Simtec Electronics IM2440D20 (Osiris)
41 CPU Module from Simtec Electronics, with a S3C2440A CPU, nand flash
42 and a PCMCIA controller.
46 Samsung's own development board, geared for PDA work.
50 The S3C2412 version of the SMDK2440.
54 The S3C2412 version of the SMDK2440.
56 Samsung/Meritech SMDK2440
58 The S3C2440 compatible version of the SMDK2440, which has the
59 option of an S3C2440 or S3C2442 CPU module.
67 Handheld (IPAQ), available in several varieties
71 S3C2440 based IPAQ, with a number of variations depending on
76 A S3C2410 based PDA from Acer. There is a Wiki page at
77 http://handhelds.org/moin/moin.cgi/AcerN30Documentation .
81 American Microsystems' M5900
86 Two machines by Nex Vision
92 The architecture has been designed to support as many machines as can
93 be configured for it in one kernel build, and any future additions
94 should keep this in mind before altering items outside of their own
97 Machine definitions should be kept in linux/arch/arm/mach-s3c2410,
98 and there are a number of examples that can be looked at.
100 Read the kernel patch submission policies as well as the
101 Documentation/arm directory before submitting patches. The
102 ARM kernel series is managed by Russell King, and has a patch system
103 located at http://www.arm.linux.org.uk/developer/patches/
104 as well as mailing lists that can be found from the same site.
106 As a courtesy, please notify <ben-linux@fluff.org> of any new
107 machines or other modifications.
109 Any large scale modifications, or new drivers should be discussed
110 on the ARM kernel mailing list (linux-arm-kernel) before being
111 attempted. See http://www.arm.linux.org.uk/mailinglists/ for the
112 mailing list information.
118 The hardware I2C core in the CPU is supported in single master
119 mode, and can be configured via platform data.
125 Support for the onboard RTC unit, including alarm function.
127 This has recently been upgraded to use the new RTC core,
128 and the module has been renamed to rtc-s3c to fit in with
129 the new rtc naming scheme.
135 The onchip watchdog is available via the standard watchdog
142 The current kernels now have support for the s3c2410 NAND
143 controller. If there are any problems the latest linux-mtd
144 code can be found from http://www.linux-mtd.infradead.org/
150 The s3c2410 serial driver provides support for the internal
151 serial ports. These devices appear as /dev/ttySAC0 through 3.
153 To create device nodes for these, use the following commands
155 mknod ttySAC0 c 204 64
156 mknod ttySAC1 c 204 65
157 mknod ttySAC2 c 204 66
163 The core contains support for manipulating the GPIO, see the
164 documentation in GPIO.txt in the same directory as this file.
170 The core provides the interface defined in the header file
171 include/asm-arm/hardware/clock.h, to allow control over the
178 For boards that provide support for suspend to RAM, the
179 system can be placed into low power suspend.
181 See Suspend.txt for more information.
187 SPI drivers are available for both the in-built hardware
188 (although there is no DMA support yet) and a generic
195 There is support for GPIO based LEDs via a platform driver
196 in the LED subsystem.
202 Whenever a device has platform specific data that is specified
203 on a per-machine basis, care should be taken to ensure the
206 1) that default data is not left in the device to confuse the
207 driver if a machine does not set it at startup
209 2) the data should (if possible) be marked as __initdata,
210 to ensure that the data is thrown away if the machine is
211 not the one currently in use.
213 The best way of doing this is to make a function that
214 kmalloc()s an area of memory, and copies the __initdata
215 and then sets the relevant device's platform data. Making
216 the function `__init` takes care of ensuring it is discarded
217 with the rest of the initialisation code
219 static __init void s3c24xx_xxx_set_platdata(struct xxx_data *pd)
221 struct s3c2410_xxx_mach_info *npd;
223 npd = kmalloc(sizeof(struct s3c2410_xxx_mach_info), GFP_KERNEL);
225 memcpy(npd, pd, sizeof(struct s3c2410_xxx_mach_info));
226 s3c_device_xxx.dev.platform_data = npd;
228 printk(KERN_ERR "no memory for xxx platform data\n");
232 Note, since the code is marked as __init, it should not be
233 exported outside arch/arm/mach-s3c2410/, or exported to
234 modules via EXPORT_SYMBOL() and related functions.
248 Guillaume Gourat (NexVision)
249 Christer Weinigel (wingel) (Acer N30)
250 Lucas Correia Villa Real (S3C2400 port)
256 Ben Dooks, (c) 2004-2005,2006 Simtec Electronics