Project

General

Profile

SciphoneDreamG2 » History » Version 13

Anonymous, 02/19/2016 10:49 PM

1 1 laforge
= Sciphone Dream G2 =
2
3
The Sciphone Dream G2 is a [wiki:MT6235] based phone running UI software to mimic the look+feel of Android.
4
5
There is currently an u-boot and Linux port for the MT6235 underway, the primary development platform is the Sciphone G2.
6
7
OsmocomBB does not yet support any Mediatek chipsets, so this phone is not supported by OsmocomBB.  Nonetheless, we
8
expect to have support for it at some point in the future.
9
10 3 laforge
More information on the hardware of the device can be found at [http://en.qi-hardware.com/wiki/Sciphone_Dream_G2]
11 2 steve-m
== Serial Cable ==
12
13
You can make a serial cable by sacrificing the headset that comes with the phone, by swapping the pins inside the connector.
14
15
Serial pinout:
16
17 9 laforge
||Pin||signal||comment||
18 2 steve-m
||1||GND||
19
||2||GND||
20 9 laforge
||5||Rx||(From PC to Phone)||
21
||7||Tx||(From Phone to PC)||
22 2 steve-m
23
[[Image(sciphone_serial.jpg,20%)]]
24
25 1 laforge
== JTAG ==
26
27
The JTAG port of the MT6235 is accessible on the phone PCB, see the attached picture.
28 5 steve-m
You can use [http://openocd.berlios.de/web/ OpenOCD] along with the attached configuration file ([raw-attachment:openocd_mt6235.cfg]) for debugging.
29 4 steve-m
30 6 laforge
[[Image(scig2_front.JPG,20%)]]
31
[[Image(scig2_jtag.jpg,20%)]]
32
33 4 steve-m
== Serial Bootloader == 
34
35 5 steve-m
Like all Mediatek MT62xx !SoCs, the phone uses the [wiki:MTKRomloader].
36 6 laforge
37 10 steve-m
For executing U-Boot and Linux using the MTK romloader, proceed as follows:
38
39 11 steve-m
 * clone osmocom-bb.git and checkout the branch 'steve-m/loader_sciphone'
40 10 steve-m
 * compile the code, connect the phone and run osmocon:
41
   {{{
42 12 steve-m
$ ./osmocon -p /dev/ttyUSB0 -m mtk ../../target/firmware/board/mt62xx/loader.mtkram.bin
43 10 steve-m
   }}}
44
 * press and '''hold''' the powerbutton of the phone, until the loading has finished and you see the following:
45
   {{{
46
[...]
47
Received branch address ack, code should run now
48
49
Running on mt62xx in environment mtkram
50
HW_CODE = 0x6235
51
   }}}
52
53
'''Uploading U-Boot'''
54
 * '''don't''' terminate osmocon and execute:
55
 {{{
56
$ ./osmoload memload 0x500000 u-boot.bin
57
$ ./osmoload jump 0x500000
58
 }}}
59
60
 * now terminate osmocon and open a serial terminal of your choice (115200-8N1)
61
 * see below for loading Linux with U-Boot
62
63 13 laforge
== MTK boot process ==
64
65
MT62xx SoCs have IPL (Initial Program Loader) saved in ROM.[[BR]]
66
67
This is first code executed after power up.[[BR]]
68
69
It configures basic functionality of CPU (serial port 19200n8) and waits on 0xA beacon.[[BR]]
70
71
If beacon won't be received, it jumps to NAND memory read procedure.[[BR]]
72
73
At 0x0 address there is Boot Header placed which holds informations about NAND memory and parameters of image which is going to be loaded.[[BR]]
74
75
NAND memory read procedure tries to read NAND memory from 0x0 address with following NFI controller settings:
76
77
||Bus width||Address bytes||Page size||Column shift||Used in Sciphone G2||
78
||1||3||512||8||||
79
||0||3||512||8||||
80
||1||4||512||8||||
81
||0||4||512||8||yes||
82
||1||4||2048||16||||
83
||0||4||2048||16||yes||
84
||1||5||2048||16||||
85
||0||4||2048||16||||
86
87
If Boot Header read from NAND memory will match to currently used NFI configuration, bootloader will start to read data from NAND to internal SRAM. Internal SRAM size is 64kB, which means that code loaded by IPL can't be bigger than that.[[BR]]
88
89
'''Note:'''IPL doesn't configure PLL and SDRAM controller, so there is no possibility to load code to external RAM here.
90
91
Here is were SPL (Secondary Program Loader) comes into the game.
92
93
== SPL - Runing U-Boot from NAND ==
94
95
SPL (Second Program Loader) is just small U-Boot loader which includes low level CPU initialization (PLL, SDRAM) and NAND driver.[[BR]]
96
97
With default build it occupies less than 4kB, but it lacks NAND memory detection. All the NAND memory types can be specified using preprocessor which is not comfortable. We already identified three different NAND memories and that would be bad to create seperate builds for them.[[BR]]
98
99
Fortunatelly there is no need to strip down SPL size to 4kB, so SPL code has been reworked and new functionalities are added. It detects NAND memory at startup and configures NFI controller automatically. New implementation can be found at "nand_spl/nand_boot_detect.c".[[BR]]
100
101
SPL also automatically configures SDRAM controler according to RAM you have on your device (currently it tries two configurations).[[BR]]
102
103
SPL is generated on every U-Boot build and binary can be found at "nand_spl/u-boot-spl.bin".[[BR]]
104
105
SPL will be loaded and executed by IPL, only if Boot Header will contain valid data (in this case checksum and length is most important).[[BR]]
106
107
There is already tool created which automatically generates Boot Header and places it at the begining of given binary. MTK Boot Header generator can be found at "tools/mtk_image.c".
108
109
{{{
110
Usage ./mtk_image [ -s size ] [ -o file ] mtk_dump.bin image.bin
111
	[ -s size ]	- size of image, if not specified file size will be taken
112
	[ -o file ]	- name of output file
113
	mtk_dump.bin	- dump of NAND memory from address 0 (at least 64 bytes)
114
	image.bin	- image to be loaded by MTK bootloader
115
}}}
116
117
118 6 laforge
== U-Boot ==
119
120
Port of U-Boot for Sciphone G2 can be found at [http://git.osmocom.org/gitweb?p=uboot-mt623x.git;a=summary U-Boot]
121
122
Building U-Boot:
123
124
{{{
125
export CROSS_COMPILE=arm-linux-gnueabi-
126
make sciphone_g2_config
127
make
128
}}}
129
130
== Linux kernel ==
131
132
Port of Linux kernel for Sciphone G2 can be found at [http://git.osmocom.org/gitweb?p=linux-mt623x.git;a=summary Linux kernel]
133
134
Building Linux:
135
136
{{{
137
export CROSS_COMPILE=arm-linux-gnueabi-
138 7 laforge
make ARCH=arm sciphone_g2_defconfig
139 6 laforge
make ARCH=arm uImage
140
}}}
141
142 8 laforge
== Building initramfs file system ==
143
144
The easiest way to have file system in Linux kernel is to build [http://www.kernel.org/doc/Documentation/filesystems/ramfs-rootfs-initramfs.txt Initramfs image].[[BR]]
145
146
You need to download [http://www.busybox.net/ Busybox], configure it and build it.
147
148
{{{
149
export CROSS_COMPILE=arm-linux-gnueabi-
150
make menuconfig
151
make
152 13 laforge
make install
153 8 laforge
}}}
154
155 13 laforge
Generated file system by default installs in _install directory.[[BR]]
156
157 8 laforge
Additional to that you'll need to create console device in already built filesystem.
158
159
{{{
160
sudo mknod dev/console c 5 1
161
}}}
162
163
Now you can create CPIO archive:
164
165
{{{
166
find . | cpio -o -H newc > rootfs.cpio
167
}}}
168
169
Next step is to point to Linux kernel where initramfs image is located.[[BR]]
170
171
In menuconfig of Linux kernel you should modify following option:
172
173
{{{
174
CONFIG_INITRAMFS_SOURCE=<path_to_cpio>
175
General setup -> Initial RAM filesystem and RAM disk -> Initramfs source file(s)
176
}}}
177
178
After these steps Linux kernel image will have initramfs built in.[[BR]]
179
180
'''Important note:''' Initramfs ignores 'init=' variable given in kernel boot parameters list. It always executes /init command at startup and you can't change it. Check if you have /init in your file system (BusyBox has /linuxrc by default, so just change its name to init).
181
Every time you change initramfs file system you have to rebuild also Linux kernel.[[BR]]
182
183
To unpack CPIO archive you can use following command:
184
185
{{{
186
cpio -i -d -H newc -F <path_to_cpio_archive> --no-absolute-filenames
187
}}}
188
189 6 laforge
== Reading data files in U-Boot ==
190
191
'''NAND'''
192
193 7 laforge
Following command will read 256 bytes from NAND address 0 at address 0x800000.
194 6 laforge
195
{{{
196 7 laforge
nand read 0x800000 0 0x100
197 6 laforge
}}}
198
199
'''Serial'''
200
201 7 laforge
Following command will read data at address 0x800000 from serial at baudrate 115200 (using kermit protocol).
202 6 laforge
203
{{{
204 7 laforge
loadb 0x800000 115200
205 6 laforge
}}}
206
207
'''SD/MMC'''
208
209 7 laforge
Following command will read uImage file at address 0x800000 from MMC card.
210 6 laforge
211
{{{
212 7 laforge
fatload mmc 0 0x800000 uImage
213 13 laforge
}}}
214
215
== NAND memory ==
216
217
So far three types of NAND memories has been identified:
218
219
||Chip||Size||
220
||HY27XS08121M||512Mb (64MB) NAND||
221
||HY27XA081G1M||1Gb (128MB) NAND||
222
||TC58NVG0S3AFT||1Gb (128MB) NAND||
223
224
All of them are supported by "mt62xx_nand.c" NAND driver in U-Boot.[[BR]]
225
226
This driver has also support for ECC hardware decoding and encoding.[[BR]]
227
228
ECC layout which is used by MTK looks as follows:
229
230
{{{
231
/*
232
 * For small and large page NAND devices ecc block size is the same:
233
 *
234
 *      ecc_block_size = 256
235
 *
236
 * Placement of ecc bytes in spare area is as follows:
237
 *
238
 * --------------------------------------------------------------
239
 * |                            SPARE                           |
240
 * --------------------------------------------------------------
241
 * |    | ECC0  |       | ECC1  |       | ECC2  |       | ECC3  |
242
 * --------------------------------------------------------------
243
 * 0    8       16      24      32      40      48      56      64
244
 *
245
 * ECC0 = 12 bits (from 1st ECC block) + 12 bits (from 2nd ECC block)
246
 * ECC1 = 12 bits (from 3rd ECC block) + 12 bits (from 4th ECC block)
247
 * ECC2 = 12 bits (from 5th ECC block) + 12 bits (from 6th ECC block)
248
 * ECC2 = 12 bits (from 7th ECC block) + 12 bits (from 8th ECC block)
249
 */
250
251
}}}
252
253
ECC layout information is pretty important as built-in bootloader in MT62xx chips
254
has hardware ECC enabled and it won't load code from NAND if ECC layout will
255
not match.[[BR]]
256
257
This layout is also important to properly dump or restore existing firmware.[[BR]]
258
259
NAND driver for Linux is under development.
260
261
== LCD ==
262
Sciphone G2 has LCD with 240x320 resolution.[[BR]]
263
264
Currently two different LCD controllers has been identified (on Sciphone G2):
265
 * ILI9331
266
 * ILI9325
267
These controllers are already supported in U-Boot.[[BR]]
268
269
To identify what kind of controller is in your device, just check U-Boot prints.
270
271
{{{
272
DRAM:  32 MiB
273
NAND:  64 MiB
274
MMC:   msdc_mmc: 0
275
mtk_lcd INFO: Read LCD device code: 9331.
276
}}}
277
278
U-Boot supports displaying bitmap on the screen, you just have to create bitmap in proper format.[[BR]]
279
280
By default U-Boot will build osmocomBB bitmap.[[BR]]
281
282
To convert your customized bitmap change type of bitmap to indexed.[[BR]]
283
284
Using GIMP, select "Image -> Mode -> Indexed...". Maximum number of colours is 240 (16 is used by internal U-Boot CMAP).[[BR]]
285
286
In existing U-Boot bmp logo converting tool (tools/bmp_logo.c) there are two issues:
287
 * width of bitmap has to be aligned to 4 (otherwise padding bytes will be added and bitmap will be not properly displayed)
288
 * size of bitmap can't be bigger than 65535 (LCD on Sciphone G2 is 240x320 = 76800)
289
Both issues are fixed on [http://git.osmocom.org/gitweb?p=uboot-mt623x.git;a=summary uboot-mt623x].[[BR]]
290
291
MT6235 LCD controller shares data lines with NFI (NAND) controller. Currently there is no possibility to use NAND when LCD is used.[[BR]]
292
293
Frame buffer driver for Linux is under development.
294
295
== U-Boot BBT handling ==
296
297
Comment from "sciphone_g2.h" configuration file explains how BBT is handled.
298
299
{{{
300
/*
301
 * Below option allows U-Boot to save BBT table in NAND.
302
 * Without this option BBT table is created everytime when first nand
303
 * command is executed (except "nand dump"). Full scanning of NAND
304
 * takes long time and unnecessarily delays first command execution.
305
 *
306
 * NOTE! This option is disabled by defaut as at startup it deletes last
307
 * two blocks of NAND. Most of people run code from RAM and don't have
308
 * NAND memory dumped yet. If you don't like to wait on first nand
309
 * command, you should enable below option.
310
 */
311
#define MT62XX_NAND_BBT_IN_NAND
312
}}}
313
314
== MTD partitions ==
315
316
Layout of MTD partitions is following:
317
318
{{{
319
device nand0 <mt62xx_nand.0>, # parts = 5
320
 #: name                size            offset          mask_flags
321
 0: sbl                 0x00020000      0x00000000      0
322
 1: env                 0x00020000      0x00020000      0
323
 2: u-boot              0x00200000      0x00040000      0
324
 3: kernel              0x00200000      0x00240000      0
325
 4: root                0x03bc0000      0x00440000      0
326 6 laforge
}}}
Add picture from clipboard (Maximum size: 48.8 MB)