1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
|
The U-Boot Driver Model Project
===============================
Block device subsystem analysis
===============================
Pavel Herrmann <morpheus.ibis@gmail.com>
2012-03-08
I) Overview
-----------
U-Boot currently implements several distinct APIs for block devices - some
drivers use the SATA API, some drivers use the IDE API, sym53c8xx and
AHCI use the SCSI API, mg_disk has a separate API, and systemace also has a
separate API. There are also MMC and USB APIs used outside of drivers/block,
those will be detailed in their specific documents.
Block devices are described by block_dev_desc structure, that holds, among
other things, the read/write/erase callbacks. Block device structures are
stored in any way depending on the API, but can be accessed by
block_dev_desc_t * $api_get_dev(int dev)
function, as seen in disk/part.c.
1) SATA interface
-----------------
The SATA interface drivers implement the following functions:
int init_sata(int dev)
int scan_sata(int dev)
ulong sata_read(int dev, ulong blknr, ulong blkcnt, void *buffer)
ulong sata_write(int dev, ulong blknr, ulong blkcnt, const void *buffer)
Block devices are kept in sata_dev_desc[], which is prefilled with values
common to all SATA devices in cmd_sata.c, and then modified in init_sata
function in the drivers. Callbacks of the block device use SATA API
directly. The sata_get_dev function is defined in cmd_sata.c.
2) SCSI interface
-----------------
The SCSI interface drivers implement the following functions:
void scsi_print_error(ccb *pccb)
int scsi_exec(ccb *pccb)
void scsi_bus_reset(void)
void scsi_low_level_init(int busdevfunc)
The SCSI API works through the scsi_exec function, the actual operation
requested is found in the ccb structure.
Block devices are kept in scsi_dev_desc[], which lives only in cmd_scsi.c.
Callbacks of the block device use functions from cmd_scsi.c, which in turn
call scsi_exec of the controller. The scsi_get_dev function is also defined
in cmd_scsi.c.
3) mg_disk interface
--------------------
The mg_disk interface drivers implement the following functions:
struct mg_drv_data* mg_get_drv_data (void)
uint mg_disk_init (void)
uint mg_disk_read (u32 addr, u8 *buff, u32 len)
uint mg_disk_write(u32 addr, u8 *buff, u32 len)
uint mg_disk_write_sects(void *buff, u32 sect_num, u32 sect_cnt)
uint mg_disk_read_sects(void *buff, u32 sect_num, u32 sect_cnt)
The mg_get_drv_data function is to be overridden per-board, but there are no
board in-tree that do this.
Only one driver for this API exists, and it only supports one block device.
Callbacks for this device are implemented in mg_disk.c and call the mg_disk
API. The mg_disk_get_dev function is defined in mg_disk.c and ignores the
device number, always returning the same device.
4) systemace interface
----------------------
The systemace interface does not define any driver API, and has no command
itself. The single defined function is systemace_get_devs() from
systemace.c, which returns a single static structure for the only supported
block device. Callbacks for this device are also implemented in systemace.c.
5) IDE interface
----------------
The IDE interface drivers implement the following functions, but only if
CONFIG_IDE_AHB is set:
uchar ide_read_register(int dev, unsigned int port);
void ide_write_register(int dev, unsigned int port, unsigned char val);
void ide_read_data(int dev, ulong *sect_buf, int words);
void ide_write_data(int dev, const ulong *sect_buf, int words);
The first two functions are called from ide_inb()/ide_outb(), and will
default to direct memory access if CONFIG_IDE_AHB is not set, or
ide_inb()/ide_outb() functions will get overridden by the board altogether.
The second two functions are called from input_data()/output_data()
functions, and also default to direct memory access, but cannot be
overridden by the board.
One function shared by IDE drivers (but not defined in ide.h) is
int ide_preinit(void)
This function gets called from ide_init in cmd_ide.c if CONFIG_IDE_PREINIT
is defined, and will do the driver-specific initialization of the device.
Block devices are kept in ide_dev_desc[], which is filled in cmd_ide.c.
Callbacks of the block device are defined in cmd_ide.c, and use the
ide_inb()/ide_outb()/input_data()/output_data() functions mentioned above.
The ide_get_dev function is defined in cmd_ide.c.
II) Approach
------------
A new block controller core and an associated API will be created to mimic the
current SATA API, its drivers will have the following ops:
struct block_ctrl_ops {
int scan(instance *i);
int reset(instance *i, int port);
lbaint_t read(instance *i, int port, lbaint_t start, lbatin_t length,
void *buffer);
lbaint_t write(instance *i, int port, lbaint_t start, lbatin_t length,
void*buffer);
}
The current sata_init() function will be changed into the driver probe()
function. The read() and write() functions should never be called directly,
instead they should be called by block device driver for disks.
Other block APIs would either be transformed into this API, or be kept as
legacy for old drivers, or be dropped altogether.
Legacy driver APIs will each have its own driver core that will contain the
shared logic, which is currently located mostly in cmd_* files. Callbacks for
block device drivers will then probably be implemented as a part of the core
logic, and will use the driver ops (which will copy current state of
respective APIs) to do the work.
All drivers will be cleaned up, most ifdefs should be converted into
platform_data, to enable support for multiple devices with different settings.
A new block device core will also be created, and will keep track of all
block devices on all interfaces.
Current block_dev_desc structure will be changed to fit the driver model, all
identification and configuration will be placed in private data, and
a single accessor and modifier will be defined, to accommodate the need for
different sets of options for different interfaces, while keeping the
structure small. The new block device drivers will have the following ops
structure (lbaint_t is either 32bit or 64bit unsigned, depending on
CONFIG_LBA48):
struct blockdev_ops {
lbaint_t (*block_read)(struct instance *i, lbaint_t start, lbaint_t blkcnt,
void *buffer);
lbaint_t (*block_write)(struct instance *i, lbaint_t start, lbaint_t blkcnt,
void *buffer);
lbaint_t (*block_erase)(struct instance *i, lbaint_t start, lbaint_t blkcnt
);
int (*get_option)(struct instance *i, enum blockdev_option_code op,
struct option *res);
int (*set_option)(struct instance *i, enum blockdev_option_code op,
struct option *val);
}
struct option {
uint32_t flags
union data {
uint64_t data_u;
char* data_s;
void* data_p;
}
}
enum blockdev_option_code {
BLKD_OPT_IFTYPE=0,
BLKD_OPT_TYPE,
BLKD_OPT_BLOCKSIZE,
BLKD_OPT_BLOCKCOUNT,
BLKD_OPT_REMOVABLE,
BLKD_OPT_LBA48,
BLKD_OPT_VENDOR,
BLKD_OPT_PRODICT,
BLKD_OPT_REVISION,
BLKD_OPT_SCSILUN,
BLKD_OPT_SCSITARGET,
BLKD_OPT_OFFSET
}
Flags in option above will contain the type of returned data (which should be
checked against what is expected, even though the option requested should
specify it), and a flag to indicate whether the returned pointer needs to be
free()'d.
The block device core will contain the logic now located in disk/part.c and
related files, and will be used to forward requests to block devices. The API
for the block device core will copy the ops of a block device (with a string
identifier instead of instance pointer). This means that partitions will also
be handled by the block device core, and exported as block devices, making
them transparent to the rest of the code.
Sadly, this will change how file systems can access the devices, and thus will
affect a lot of places. However, these changes should be localized and easy to
implement.
AHCI driver will be rewritten to fit the new unified block controller API,
making SCSI API easy to merge with sym53c8xx, or remove it once the device
driver has died.
Optionally, IDE core may be changed into one driver with unified block
controller API, as most of it is already in one place and device drivers are
just sets of hooks. Additionally, mg_disk driver is unused and may be removed
in near future.
III) Analysis of in-tree drivers
--------------------------------
1) ahci.c
---------
SCSI API, will be rewritten for a different API.
2) ata_piix.c
-------------
SATA API, easy to port.
3) fsl_sata.c
-------------
SATA API, few CONFIG macros, easy to port.
4) ftide020.c
-------------
IDE API, defines CONFIG_IDE_AHB and ide_preinit hook functions.
5) mg_disk.c
------------
Single driver with mg_disk API, not much to change, easy to port.
6) mvsata_ide.c
---------------
IDE API, only defines ide_preinit hook function.
7) mxc_ata.c
------------
IDE API, only defines ide_preinit hook function.
8) pata_bfin.c
--------------
SATA API, easy to port.
9) sata_dwc.c
-------------
SATA API, easy to port.
10) sata_sil3114.c
------------------
SATA API, easy to port.
11) sata_sil.c
--------------
SATA API, easy to port.
12) sil680.c
------------
IDE API, only defines ide_preinit hook function.
13) sym53c8xx.c
---------------
SCSI API, may be merged with code from cmd_scsi.
14) systemace.c
---------------
Single driver with systemace API, not much to change, easy to port.
|
