-
Notifications
You must be signed in to change notification settings - Fork 2
/
log200909vimicro.txt
2774 lines (2436 loc) · 156 KB
/
log200909vimicro.txt
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
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
11:00 2009-9-1
Linux移植, uart, 文件系统, bosybox-1.14.3, <TODO></TODO>
1, busybox的ash读取串口过程如下:
parsecmd()->readtoken()->xxreadtoken()->pgetc_fast(), pgetc()
pgetc()->pgetc_as_macro()->preadbuffer()->preadfd()->nonblock_safe_read()
nonblock_safe_read()->safe_read()->read()
从中可以看出, 最后还是通过系统调用read实现的. 所以tty分析的重点应当是write和read函数.
2, busybox console_init()(init/init.c), 说明了如何open串口:
int fd = open(s, O_RDWR | O_NONBLOCK | O_NOCTTY);
if (fd >= 0) {
dup2(fd, STDIN_FILENO);
dup2(fd, STDOUT_FILENO);
xmove_fd(fd, STDERR_FILENO);
}
18:14 2009-9-1
Linux移植, uart, 文件系统, 进展
1, 今天zhicheng发现如果tx_empty直接返回1就有kernel panic, 感觉是tx_empty使用问题
uart_ioctl()->uart_get_lsr_info()->port->ops->tx_empty(port)
tty_wait_until_sent()->uart_ops.wait_until_sent(uart_wait_until_sent())->port->ops->tx_empty(port)(while循环, 直到empty退出)
2, 调用"tty_wait_until_sent"的通用函数有:
1), uart_close(drivers\serial\serial_core.c)
->tty_wait_until_sent(tty, msecs_to_jiffies(state->closing_wait));
uart_close这个函数会被tty的release函数调用.
2), set_termios(drivers\char\tty_ioctl.c)->tty_wait_until_sent(tty, 0);
3), tty_set_ldisc(drivers\char\tty_ldisc.c)->tty_wait_until_sent(tty, 0);
3, uart_wait_until_sent分析.
可以看出如果超时退出, 有signal也有退出. 所以只要"port->ops->tx_empty(port)(vc0830_uart_tx_empty)"实现正确, 这里不应该会死等.
另外每次的超时时间char_time是与fifosize有关, 可以估算一下830会不会超时.
4, 从上面分析看咱们目前的vc0830_tx_chars不太合理.
咱们uart没有fifo, 把fifosize设为1比较合理. 然后vc0830_tx_chars中不等发送发成, 改为在tx_empty()(vc0830_uart_tx_empty)中等待. 这样更符合linux uart架构.
10:42 2009-9-2
时间管理
10:00-10:40: 与zhicheng讨论Linux uart
10:40-11:10 看邮件, 回邮件.
12:44 2009-9-2
<TODO>继续整理</TODO>
uart_ops.write(uart_write(), drviers\serial/serial_core.c)和fluash_char都会调用uart_start.
其中uart_write会一次把用户传入数据写入xmit buffer, 所以uart start需要一次把这些数据都发送出去.
13:33 2009-9-2
VC0830, SV, clkrst, clkswitch, 继续完成打包切频工具
之前的批量切频工具可以完成批量切频测试, 目前pcddr, sdram切频流程已经稳定, 希望把batchswitch info也用于aasp中的切频. 这样达到代码与数据的分离. 需要做的工作
1, clkrst_init中需要把batchswitch info从0x200000移到malloc的区域, 避免被后面的malloc破坏.
2, 为用户数据建立单独的用户TMemoryInfo. 如果有g_userMemInfo, 以此为默认memoryInfo.
3, 切频相关函数的修改:
1), 频点只能从用户频点中选择, 需要修改Clkrst_App_PrintAllCpu().
2), 频点的限制通过get memory info中能否得到对应memory info控制.
Clkrst_MemParm_DefaultGet()改为两种方式:
(1), 如果是g_userMemInfo, 只查找该频点是否存在.
(2), 如果不是, 按现有方式.
Q: 二者为什么不能合并和?
A: 因为前者提供的频点和memory参数一一对应, 有时会造成bus频率相关, bus divider相同但参数不同的情况. 使用方法(2)必须要求memory参数只和bus频率, bus divider相关.
4, batchswitch函数本身应当使用移动后的info, 而不是0x200000的.
5, <TODO>bug, 明天找linchuan</TODO>:
发现如果判断了sdrc_mode是否变化, 有时会判断错误, 导致切频死:
if ( 1 /* && sdrc_mode_prev != clockSwitchInfo->memParm->sdrc_mode*/ ) {
18:32 2009-9-2
VC0830, SV, clkrst, clkswitch, eorex_6切频问题
Sdram 要求1， -6 （312，156）-7.5（264，132），2，（360，120），3（288，96）4（288，72）5（192，48）6（96，24）
22:37 2009-9-2
VC0830, SV, clkrst, clkswitch, 时间管理
今天下班哪会儿(18:00-19:25)心里有点乱了, 应该静下心来分析一下.
感觉eorex-6芯片切频有问题可能是sdram切频还没有完成, 或没有稳定. 考虑用下面三个方法:
1), 返回前读取memory特定地址的数据. 为了简单可以直接读取sram切频程序部分. 这段程序不会执行, 所以不会在cache里面.
2), 返回前加入足够的nop, nop数量参考lvpin邮件. 如果没找到, 暂时用800nop代替.
\todo 需要查一下上次为什么要加nop. 在sram中的代码, 加入while循环应该也是一样的.
3), 查询发送自刷新命令后, 是否真的进入了自刷新.
4), 对于eorex_6, 切频时不修改sdrc_mode, 把sdrc_mode和rd_path_ctrl的Tcas和CL延时同时增加1.
反思: 从时间管理角度看. 造成我下班是紧张的原因是没法按时提交高低温测试. 没法按时提交高低温测试的原因又是因为优先安排了"不紧急, 重要"的任务(通过打包方式配置频点和memory参数). 本来预期是这个任务完成后, eorex_6高低温实验用这个工具做, 正好检验工具是否好用, 但是这个工具所需时间长于预期(这类预期时间小于实际时间的情况我多次遇到), 造成现在这个结果. 由于已经到了下班时间, 也没法找IC同事讨论.
9:47 2009-9-3
VC0830, SV, clkrst, clkswitch, 继续解决昨天eorex_6切频问题
1, 实验昨天的四个方法:
1), 实验3), fail.
2), 用方法2), 加入延时, 开始感觉也是按单步就行. 后来看sdrc寄存器时, 突然发现有频点timing配置不正确. 进一步检查发现有三个频点参数有错误. 昨天实在太着急了.
3), 修改参数后发现每次切到xclk时不会进入自刷新. 与LinChuan讨论:
发现eorex_6这个屏的sdrc_cfg是"0x6959aa95", 6
sdrc_timing(0x60011008)bit[28,31]
31:28 TASE Preset value for automatic self- refresh Mode Timer
Preset value = (Tase + 1) * 16 cycles RW 4'hf
所以6表示(6+1)x16=112cycle后进入自刷新, 但是xclk下sdrc_refresh(0x6001100c)是0x60(96), 每隔96个cycle会刷新sdram, 小于112, 也就是说112个cycle内必然有sdram访问. 为了避免这个问题, sram切频时修改为0, 切频后改为原有值.
注意: 这个值越小对性能影响越大, 因为memory退出自刷新不能立刻访问.
2, 下午继续实验.
1), 发现修改后除了720_360_120以外都可以. 先不考虑这个频点, 切1000轮 pass
2), 发现720_360_120死在切频后的updata_module_divider. 如果在sram代码跳回sdram前设断点, 手动切频100次就没问题.
3), 昨天想的四点中还有1), 4)没有实验, 加上方法1)实验.
此时core=1.44
先实验除了360_120以外的5个频点, 切频2000轮, pass
如果pass, 专门实验720_360_120这个频点. 切频1778轮, pass, 现在不行了(core=1.23). 奇怪.
后来发现是电压问题, core升到1.5v切2万轮没问题.
3, 大量测试. 上面那个板子是tomli(core=1.5, memory=3.31)
1), #9. core=1.45, memory=3.33
2), tomLi板子core=1.45, 切频几十次会死在720_360_120,
4, (20:38 2009-9-3)(9:44 2009-9-4)
高低温切频实验随机测试youhai提供的6个频点: 1, （312，156），2，（360，120），3（288，96）4（288，72）5（192，48）6（96，24）
1), 720_360_120频点在常温下加压对稳定性有一定改善, 但同样电压下高温切频不稳定. 去掉720_360_120后, 其余5个频点常温切频12小时稳定, 高温1个板子pass.2个板子fail.
(1), 包括720_360_120等6个频点:
tomli板子: core=1.5, #9: core=1.45
常温:
tomli板子和#9板子都切频2万轮(共6个频点)pass.
高温:
tomli板子 切到360轮后死在720_360_120频点, 复位2次都是第一次切到720_360_120死.
#9 切几次后死在720_360_120, 复位2次都是第一次切到720_360_120死.
(2), 去掉720_360_120频点, 最高频点是312_156, 共5个频点. 调整core=1.42.
常温切频2000轮pass. 高温测试tomli板312_156频点切频几轮内死(共实验5次). 怀疑是板子问题换另一个板子. 换#0板, 第一次也是很快死, 第二次也很快死.
#9板子高温切频6.6万轮.
tomli板子常温切频6.5万轮没有问题. 说明是高温问题.
"9:44 2009-9-4"end
delay原因补充:
1, xclk下无法进入自刷新造成切频无法继续, 9月2日上午与linchuan讨论后解决.
2, 720_360_120不稳定, 排查问题.
3, eorex_6能用的片子到9月2日下午前只有一个, 无法一边测试一边debug.
5, 测试vdec
1), 切频, open屏, ls时出现大量marb apb timeout. 查原因. ls时会死.
(1), clksv中时i2c操作函数会引起marb apb timeout
(2), ls时死在read 等cmd complete.
EVB hynix板子问题相同. 看来是batchswitch code问题.
10:52 2009-9-3
VC0830, SV, <TODO></TODO>
0, 晚上把heming简历发给aiguo.
2, EVB pcddr sdrc_mode不变情况下反而有问题, linchuan感觉可能是nop问题, 尝试.
3, SV sdram切频用目前code有问题. 查原因.
4, MP4切频有的屏幕会闪白, 估计闪白的原因是切频时pclk被gate了, 目前youhai的解决办法是切频时把背光关了.
这个是个案, 一般的屏都没这个问题, youhai实验过播MP4过程中1ms切频一次, 是没问题的.
5, sram切频code不应当其它链接脚本.
6, sdrc_timeing中如下两位有什么区别?
31:28 TASE Preset value for automatic self- refresh Mode Timer Preset value = (Tase + 1) * 16 cycles RW 4'hf
19:16 TRFC Auto Refresh Period 0000-1111: 1-16 cycles RW 4'hf
9:00 2009-9-4
VC0830, Linux移植进展
review uart driver代码后/dev/console输出仍有问题, 无论我们start_tx一次打印几个字符, 现象是只打印两次. 之前分析发送代码时不同sos uart fifosize设置不同, 所以感觉是fifosize影响. 后来发现除了uart_wait_until_sent外都未使用该变量.
暂时放下底层代码分析tty流程:
redirect_tty_write -> tty_write -> write_chans(n_tty.c, 系统注册的默认tty line discipline, 实际硬件是uart) -> uart_write / flush_char -> uart_start -> __uart_start -> vc0830_start_tx -> vc0830_tx_chars.
write_chans 是把所有字符通过opost写入xmit缓冲后,调用一次uart_write / flush_char. 所以后面的start_tx必须保证调用一次就发送完xmit中所有字符.
这里一般方式是利用发送中断反复发送, 但我们没有发送中断. 所以只能在start_tx直接调用tx_char一次发送.
13:53 2009-9-4
VC0830, SV, clkrst, clkswitch, linchuan, dram配置参数说明
<TODO>很有的说明, 细看</TODO>
位置: D:\work\VC0830\SV\clk
13:54 2009-9-4
时间管理:
1, 今天计划:
1), 1小时时间完成脚本配置eorex切频工具, release给dashan.
2), 其余时间调试vdec 720p脚本配置为什么会出现marb apb timeout. 有问题及时与IC同事讨论.
2, 实际进度
1),
13:56 完成脚本配置eorex切频工具
14:50 2009-9-4
VC0830, 软件技巧, clkrst, clkswitch, 打包切频工具, rvdebug使用技巧, 续
1, 为了调试需要在0x20000处写入数据, 可以把打包工具生成的info load到memory, 或者在rvdebug 命令行copy已有结构体到0x20000处.
1), load pakinfo到memory:
菜单: Debug -> "Memory/Register Operation" -> "Upload/Download file from/to Memory",
rawb模式格式与bin相同, 如果采用rawb模式load文件"D:\work\VC0830\SV\code_image\20090904\1414_timer_sv_EVBsdramEorex6_batchswitch.pakinfo"到memory 0x200000处, 对应命令如下:
readfile,rawb,gui "D:\work\VC0830\SV\code_image\20090904\1414_timer_sv_EVBsdramEorex6_batchswitch.pakinfo"=0x200000
2), 方法二
(1), 查rvdebug help
COPY
Copies the contents of a specified block of memory to a block of the same size starting at a specified location.
Syntax
COPY addressrange, targetaddr
For more details, see the RealView Debugger v1.8 Command Line Reference Guide.
(2), 仍是不太明白, 根据提示去开始菜单找到pdf
"C:\Program Files\ARM\Documentation\RVD\1.8\release\windows\PDF\DUI0175F_rvd_cli_guide.pdf"
找到如下例子:
The following examples show how to use COPY:
copy 0x8100..0x81FF,0x8700
Copies the contents of memory at 0x8100 to 0x81FF to memory at 0x8700
to 087FF.
copy 0x8100..+128,0x8700
Copies the contents of memory at 0x8100 to 0x817F to memory at 0x8700
to 0877F.
这样就清楚了.
2, 调试发现是"SpiScanMemPack"工具没有同步更新TBatchSwitch变化.
在TBatchSwitch尾部加入magic和版本号, 如果不同也要提示.
结构体修改完成, 修改代码, Clkrst_App_IsBatchSwitch: Clkrst_App_IsBatchSwitch中即使是debug, 也要查magic.
3, 昨天marb apb timeout的问题果然是gate了m_gt寄存器对应模块的bit. 当初batchswitch时gate了多数模块, 本来想将来再ungate的. 自己忘了.
4,
1), 把312_156改为156_156, 去掉360_120, 共5个频点, 用昨天312_156高温fail的板子(#0)做高温切频实验. 发信时说明#0板子的memory片子不一定是昨天的.
切频40分钟 2600轮没有问题.
2), 常温312_156_156 720p 播40000 frames未出错.
5, 发信
eorex目前测试情况(周四周五总结)
测试结果不好. 高温下cpu在312, 360都不稳定. 高温bus在156MHz目前看是稳定的.
1), 切频测试
测试如下6个频点（312，156）（360，120）（288，96）（288，72）（192，48）（96，24）
(1), 720_360_120频点在常温下加压对稳定性有一定改善, 但同样电压下高温切频不稳定. (2), 720_360_120后, 其余5个频点常温切频12小时稳定, 高温1个板子pass.2个板子fail.
(3), 把测试(2)的312_156改为156_156, （156，156）（288，96）（288，72）（192，48）（96，24）5个频点高温切频测试, 测试进行中.目前切频40分钟 2600轮没有问题.
2), 720p播放测试:
312_156频点常温720p播放40000 frames未出错.
6, <TODO>测试autoswitch, EVBhunix, SV mobile ddr, SV sdram三星</TODO>
测试标准定为: 切频测试1000次, 已有最高频率720p dixinyouji 4000frame pass.
1), 当初写"Clkrst_App_BatchSwitch"没有加入clkrst模块的autoswitch命令. 目前也不打算加入这个命令. 希望Clkrst_App_BatchSwitch是个相对轻量级的自动切频code.
2), 还需要考虑编译其它脚本时可以编译. 周一先merge最新代码, 再继续测试.
22:51 2009-9-4
VC0830, Linux移植
1, 紧急, 重要: 8月总结; 这是要养成的习惯, 加油.
2, Linux移植思路整理(含本周进展). 不紧急, 重要.
10:05 2009-9-7
时间管理
1, table
10:00 - 10:35 切频打包工具给dashan
10:40 2009-9-7
VC0830, SV, clkrst, clkswitch,<TODO></TODO>
1, 早晨看了邮件, 主要是切频的事. dashan要实验出cpu,bus,vdec最高频率.
10:41 2009-9-7
Linux移植, uart, 文件系统, busybox, Linux移植进展, 工作总结, 本周工作总结, 2009年8月31日--2009年9月4日
1, 周进展和总结(2009年8月31日--2009年9月4日)
解决kernel panic和uart只发送两次两个问题(liaozhicheng):
1), 解决kernel panic
helloworld虽然正常打印(只是fifosize=16时正常, fifosize小的时候打印不全), 但是后面没有kernel panic, 这是遗留很久的问题了. 既然helloworld看起来正常, 下一步是busybox能跑起来. 这之前希望解决kernel panic不出现这个问题, 担心隐藏了问题.
(1), 开始没什么思路, 比较盲目(具体过程我不太清楚, 请zhicheng补充). 后来偶然发现 vc0830_uart_tx_empty() 直接返回0的话是可以打印kernel panic的.
(2), 分析 vc0830_uart_tx_empty() 函数
vc0830_uart_tx_empty是 uart_ops.tx_empty 用于查询发送缓冲是否为空(初步分析结果). 返回 TIOCSER_TEMT 表示 Transmitter physically empty. ( TIOCSER_TEMT 定义见 ioctls.h (arch\arm\include\asm) ), 返回0表示非空.
uart_ops.tx_empty 有三处调用:
A, uart_ioctl()->uart_get_lsr_info()->port->ops->tx_empty(port)(serial_core.c (drivers\serial))
B, tty_wait_until_sent()->uart_ops.wait_until_sent(uart_wait_until_sent())->port->ops->tx_empty(port)(while循环, 直到empty或timeout退出)
C, uart_suspend_port(): serial_core.c (drivers\serial): for (tries = 3; !ops->tx_empty(port) && tries; tries--)
A,C两处与发送函数关系不大, 重点分析B.
(3), 调用"tty_wait_until_sent"的通用函数有:
1), uart_close(drivers\serial\serial_core.c)
->tty_wait_until_sent(tty, msecs_to_jiffies(state->closing_wait));
uart_close这个函数会被tty的release函数调用.
2), set_termios(drivers\char\tty_ioctl.c)->tty_wait_until_sent(tty, 0);
3), tty_set_ldisc(drivers\char\tty_ldisc.c)->tty_wait_until_sent(tty, 0);
(4), 从tx_empty的调用关系没看出什么端倪,
不知道是哪里出的问题, uart_wait_until_sent没有正常返回像是调度出了问题. 这期间在qmeu realview和VC0830上对比函数调用关系, 最后发现是 uart_wait_until_sent 的char_time不正常. char_time计算公式: char_time = (port->timeout - HZ/50) / port->fifosize; char_time = char_time / 5;
port->timeout 原来没有用过. 需要分析. 其余变量都很明确:
struct uart_state *state = tty->driver_data;
struct uart_port *port = state->port;
tty是传入的tty_struct: static void uart_wait_until_sent(struct tty_struct *tty, int timeout).
(5), 搜索timeout很多, 直接搜索port->timeout.
发现 uart_update_timeout 会设置port->timeout:
bits = bits * port->fifosize;
port->timeout = (HZ * bits) / baud + HZ/50;
"baud/bits"表示uart在1秒内发送的次数. 其倒数是时间, 所以"(HZ * bits) / baud"是uart完成一次发送需要jiffies数.
所以 char_time = (port->timeout - HZ/50) / port->fifosize = HZ * bits / baud;
如果是8位, 115200, char_time = 0.00694, char_time=char_time/5=..., 所以uart_wait_until_sent会round到1.
结合注释看, char_time(除5之前)是发送一个uart 发送一个字符需要的jiffies数, 对于115200 8n1的uart, uart发送一个字符的时间肯定是远小于一个jiffies的.
<TODO>需要确认分析的是否准确</TODO>
(6), 从其它移植看, uart_update_timeout 应当在 uart_ops.set_termios 中设置. 我们的 set_termios 当时是想固定死115200 8n1所以基本就没参考其它uart的写法, 这是个疏漏. 其实uart移植中遇到的问题多数是没有依照规范移植的结果. 最早分析uart时zhangjian着重分析了printk相关内容, 后来zhicheng实际做的时候才发现用户空间的tty所需的uart驱动部分比printk部分复杂很多.
<TODO>总结</TODO>: 当时给我的uart和clock, 应当是按照缓急先做uart, 当时为了完成clock分析和建立文档所以花大量时间在clock上. 现在看来应该是先认真分析uart. 不过后来采用qemu虚拟机辅助分析是个好方法.
4), 解决uart只发送了两次的问题.
由于分析830代码暂时没有进展, 转而分析tty调用流程:
(/dev/console): redirect_tty_write() -> tty_write() -> write_chan()(n_tty.c, 系统注册的默认tty line discipline, 实际硬件是uart) -> uart_write()(uart_ops.write, uart_ops是struct tty_operations) / uart_flush_chars()(uart_ops.flush_chars) -> uart_start() -> __uart_start() -> vc0830_start_tx() -> vc0830_tx_chars()
write_chans 是把所有字符通过opost写入xmit缓冲后,调用一次uart_write发送这个字符. 所以后面的start_tx必须保证调用一次就发送完xmit中所有字符.
Linux一般方式是利用发送中断反复发送, 但我们没有发送中断. 所以只能在start_tx直接调用tx_char一次发送.
2, 发现的问题:
1), 本周发现原来的的vc0830_tx_chars不太合理. 830 uart没有fifo, 把fifosize设为1比较合理. 然后vc0830_tx_chars中不等发送发成, 改为在tx_empty()(vc0830_uart_tx_empty)中等待. 这样更符合linux uart架构.
2), 1-2)中提到的uart没有发送中断的问题.
3, 下周计划
根据busybox过程, 测试/dev/console和/dev/ttyS0
busybox前面先执行了linuxrc, 需要确认直接执行init是否可以正常登录. 如果可以按init.c: init_main()->console_init()这个思路实验就没问题.
14:40 2009-9-7
<TODO>看3520邮件</TODO>
17:58 2009-9-7
(15:19 2009-9-22)
Linux移植, uart, 文件系统, busybox, 今日进展, 本日工作总结, 2009年9月7日, busybox登录过程分析, 登录出问题的debug方法
1, 基于上周分析的结果, 这周从分析busybox机制开始.
1), 今天结合代码和打印分析了busybox启动流程.
(1), 总的调用关系
init_main() -> run_action() -> run() -> getty_main() -> parse_args() -> get_logname()
(2), parse_args(): 处理命令行参数, 例如inittab中的"/sbin/getty -L ttyS0 115200 xterm", 如果登录有问题, 可以在这里加入打印信息, 这样就能知道getty操作的哪个串口.
(3), get_logname(): 显示login提示符, 具体过程:
get_logname() -> sleep(1) //这个地方830没有返回.
-> do_prompt() -> print_login_prompt() //这个函数打印
出"hostname login:"的提示符.
-> (输入用户名密码正确后) -> login_main()(login_main()是
getty_main()调用BB_EXECLP宏(exe*函数)执行的.
2), 发现830在sleep(1)后没有返回. 说明可能是sleep有问题. 注释sleep后可以显示出login提示符. 但是输入没有反应. 加入打印信息后发现没有进入830 uart接收中断.
(21:23 2009-9-9)后来发现是putty问题. 见"19:45 2009-9-9"
2, 从楼下拿到830kernel, 使用的是android 2.6.27kernel, 据了解已经有了最小环境以及framebuffer, USB net驱动.
位置: \\10.0.2.36\sqmshare\Share\aiguo\linux\836EVB
3, 近期计划:
希望从现在开始用一个月时间完成Linux基本环境, 驱动包括framebuffer, USB net和storage(sd或nand)
19:05 2009-9-7
dave婚纱照
http://bbs.55bbs.com/thread-2809838-1-1.html
19:59 2009-9-7
Linux移植进展, 工作总结, 2009年8月22日--2009年8月27日, 0821更早的移植我没有参与, 请zhicheng补充.
0822,23文件系统如何配置,cpio如何打包
0824, 0825: 怀疑是load elf出错, 用qemu和rvdebug配合调试, 确认已经进入用户空间. 而且有kernel panic.
0826: 分析用户空间写串口过程中, 内核处理过程, helloworld 可以正常显示. 但后来发现底层串口输出函数只调用了两次, 仍有问题.
0827下午: review uart代码, 未完成.
20:10 2009-9-7
VC0830, SV, MP4项目进展, 重要
StevenLiu邮件"答复: VC0831 Task Tracking List_20090904"20090907_2007
Zhihong，MKV的问题已通过测试，可以close。
删除第23行和第18行的任务，因为已经在别的任务中cover了。
根据目前状况需要加入的任务有：
4.3”样机上还有较多的问题，要集中再debug一次，周末要release出去（高优先）把下面红色字列个专项表格出来，落实到人，周五搞定。
3”样机上菜单刷屏慢（高优先）
3”样机上CVBS输出有较多丢帧（高优先）
5MP sensor调试（列入middle priority）
1.一般性死机 1个，随机性的和例外死机 5个(具体现象见附件)
2.播放FLV文件一会后，没有声音输出，进行快进后只有“咔咔”杂音(具体现象见附件)
3.播放歌曲时，背光灭，播放一段时间后，按任意键点亮屏时，会显示白屏、花屏、红屏、蓝屏、绿屏。(具体现象见附件)
4.低电关机后，出现Nand为0KB(第一次低电关机不显示低电提示画面时，就会出现OKB)
5.播放“高低音DJ试音曲.mp3”、“FLY.ape”或“44.1kHz-192kbps-Stereo-光良-童话.wma”等部分音乐文件时背光灭->按遥控板上的任意键点亮屏->【长按遥控板上的Next键】快进到末尾->松开按键后不会自动跳曲，声音播放结束后才会跳曲
6.播放VBR歌曲(如“22.05kHz-60Kbps(VBR)-Stereo-22kHz-VBR-046郑源-一万个理由.mp3”等)->快进到末尾后松开按键->不自动跳曲，要等声音播放结束后才会跳曲
7.提取书签后，无法进行翻页
8.信息栏的电池Icon经常显示为空格，电池检测不准
9.低电关机后，【按OK键】或插入充电->闪一下白屏
10.任意界面->将开关打到OFF，再打到ON->开机，会闪下白屏
11.在任意界面，背光灭时->有“啪”的一声(按键点亮屏时也有“啪”的一声)
12.【长按OK键】开机或关机->有“啪”的一声
13.将音量调到32后，长时间用喇叭输出播放视频或音乐，喇叭容易被烧坏
14.播放VOB文件时，严重卡，AV不同步
15.电子书自动浏览时，有时会以1秒的速度自动翻几页
16.在电子书列表添加文件到我的收藏夹后，在“我的最爱”中找不到文件(添加的文件不保存)
17.播放分辨率小于720P的文件时，进行基本操作后，视频播放界面有横的或竖的白色长条(具体现象见附件)
18. TV输出时->进入系统设置->选择电视输出->选择关闭->【按OK键】确定输出到LCD上->样机显示白屏、红屏、蓝屏、绿屏等
19. CVBS输出->任意界面显示模糊，有很多雪花点
20. TV输出时样机闪屏、花屏严重
21:43 2009-9-7
VC0830, SV, clkrst, clkswitch, 代码整理, 验证切频打包工具
1,
1), 刚才sdram出错原因是sdram中没有开自动自刷新, 在sram切频代码中加入了开启自动自刷新的代码, 需要回归测试EVB的sdram和pcddr是否可用.
2), 之前代码没有考虑sdram下medium=xclk时, pll1->pll2切频流程. 所以batchswtich中
if (
curClkSrc == mediumInfo.clksource_index
|| mediumInfo.clksource_index == switchInfo.clksource_index
) {
改为
( PLL1_ID == curClkSrc && PLL2_ID == switchInfo.clksource_index )
|| ( PLL2_ID == curClkSrc && PLL1_ID == switchInfo.clksource_index )
|| ( PLL1_ID == curClkSrc && XCLK_ID == switchInfo.clksource_index )
|| ( XCLK_ID == curClkSrc && PLL1_ID == switchInfo.clksource_index )
2, 如果今晚实验顺利, 明天测试282 mddr. 同时修改代码保证其它脚本能编译通过.
(12:59 2009-9-8)实验结果:
SV LQFP176 sdramSamsung: 切频75847轮(5个频点, 约15小时)pass;
EVB sdram eorex_6: 78836轮(5个频点, 约15小时)pass
10:01 2009-9-8
VC0830, SV, 量产, Wafer, 832成品率已经提高到80%?
830 Wafer Test Program
1. 832program PLL调试问题已经解决，Yield提到80%，仍在继续调整
2. 898Pattern已经Release到TW。
10:06 2009-9-8
时间管理
1, table
1), 9:40-10:08 邮件, 关注830量产进度, bug解决进展.
2), 10:08-11:06 整理早晨手机工作日志, 上周总结
10:11 2009-9-8
VC0830, 周工作总结, 2009年8月31日-2009年9月4日, EVB pcddrHynix切频fail原因, EVB sdramEorex_6切频, 打包切频工具, sdrc寄存器学习(auto refresh, self refresh区别和配置方法, 重要), 反思时间安排不合理的地方
1, 主要工作:
20090831: 发现对于EVB pcddr Hynix, 如果sdrc_mode不变时不进入sram切频流程, 切频有时会失败
20090901: 继续解决Linux移植uart和文件系统问题
20090902:打包切频工具和evb board eorex_6切频.
20090903:打包切频工具续1和evb board eorex_6切频续1
20090904:打包切频工具续2
2, 经验总结:
1), 20090902同时做打包切频工具和evb板eorex_6 sdram两个事, 前者重要不紧急, 后者紧急重要. 开始预期切频流程已经稳定, 后者不会有困难.
实际情况是两者混在一起引入了更多的问题.
2), 20090903: eorex_6遇到的问题: 三个频点8sdrc timing参数填错,xclk自刷新周期影响无法进入自动自刷新, 720_360_120是cpu频率过高.
3), 疑问: auto refresh和self refresh区别, TASE, TRFC等的含义
(1), autorefresh是指sdrc发送auto refresh command刷新dram. 发送周期从dram datasheet读出, 例如sdram samsung 写着64ms refresh period (8K Cycle), 也就是auto refresh 周期 = bus * 64ms / 8k = bus * 64000 / 8192 =(约等于)= bus * 8. 配置到sdrc_refresh寄存器.
dram要求做auto refresh时一定时间内不能有其它命令, 这个时间有sdrc_timing的TRFC配置(有时datesheet不全没写这个timing, 找个完整的datasheet看):
19:16 TRFC Auto Refresh Period
0000-1111: 1-16 cycles RW 4'hf
(2), self refresh是指dram不使用cpu提供的clk, 自己进行刷新. 这是一种低功耗模式, 但是退出self refresh需要一定时间才能工作, 所以进去self-refresh过快会影响性能.
dram判断进行self refresh的时间通过sdrc_timing的TASE设置:
31:28 TASE Preset value for automatic self- refresh Mode Timer
Preset value = (Tase + 1) * 16 cycles RW 4'hf
TASE是否有效有sdrc_cfg的AUTOSELFREFRESHENTRY控制
9 AUTOSELFREFRESHENTRY When SDRC is in idle state, internal timer starts counting. When SDRC internal timer reaches preset value, SDRC will issue self-refresh command to SDRAM/DDR device for saving power. SDRAM/DDR clock is gated by SDRC. SDRC internal FSM keeps the state until MARB needs access to SDRAM/DDR device or SW issues exiting self-refresh command. Preset value for internal timer is determined by SDRC_TIMING[31:28]
0: disable auto-enter self-refresh mode entry
1: enable auto-enter self-refresh mode entry RW 1'b0
(3), 两个refresh与切频的关系:
A, auto refresh与频率有关, 所以要求切频时根据bus频率配置. 实际操作中分两个情况:
i, 如果是用户通过打包切频工具传入的频点和dram参数, 需要用户自己计算sdrc_refresh.
ii, 如果是用户在mem_memType_memVender配置memory参数, 需要提供PTMemoryParm->getSdrcRefresh函数, 根据传入的bus频率计算sdrc_refresh.
B, self refresh是低功耗模式, 从EVB板的pcddr hynix开始, 包括EVB sdram eorex都把sdrc_cfg的auto-entry self-refresh打开. 切频时设置sdrc_mode之前为了包括对dram没有访问, 要查询dram是否进入了self refresh(如果没有打开auto-entry self-refresh, 打开之), 确定进入self refresh后通过sdrc_cmd(0x60011014)寄存器发送"00011: Self Refresh Exit (SLFRSHX)"命令退出self refresh, 发送后查询是否退出self refresh, 确定退出后修改sdrc_mode, 发送MRS, 根据sdrc_cfg配置发送EMRS. 完成后再打开auto-entry self-refresh. 具体sram切频流程参见clkrst/drv/clkrst_drv.c的Clkrst_Drv_TriggerSwitch()函数.
注: 这里的sram切频流程指为了修改sdrc_mode走的特殊切频流程, 如果sdrc_mode永远不需要改变, 直接trigger switch即可, 不需要sram切频流程. 目前为了统一和简化, 所有情况下都走sram切频流程.
10:27 2009-9-8
VC0830, SV, sdrc, clkrst, clkswitch, dram(sdram/pcddr/mobile ddr) data sheet位置
ftp://10.0.2.109/VC0830/boards/VC0830-FPGA/%5BDRAM-Datasheet%5D/
12:59 2009-9-8
VC0830, SV, clkrst, clkswitch, 打包切频工具
1, EVB pcddr hynix:
切频到pll2后, 再切回pll1, open时有marb apb timeout
发现是切到pll2后gate了iclk, 深层原因是cpu,bus频率计算不正确(应当是120_120, 实际是240_240), 参考816代码加入了c_clk_pll2f2用来表示pll2 fout2这个输出.
2, 其它问题
1), print cpu freq时区分cpu clocksoure, 并排序.
排序这是事用了100分钟, 当初数据结构和算法学的确实不怎么样. 也凸显编程基本功仍然不过关. 所以像目前这样多coding对我大有好处.
这次的主要错误是"++"用的不对. 结果比预期多加了一次:
需要把"while ( data < *array++ );"改为"while ( data < *array ) array++;"
前者是任何条件都自增, 后者是满足条件才自增, 条件不满足退出循环.
3,
1), 目前只有"dram32M_4bank_dynamic.lds"(默认脚本)支持sram切频流程, 如果不使用此脚本需要注释sys.h的"CLKRST_SRAM_SWITCH_FUNC_SUPPORT"关闭sram切频流程.
4, CVS
1), VC0830(上传时点错了, 如下log没有贴入CVS), 如果pass打个tag.
(1), 允许用户使用打包的batchswitch info切频. 这样实验不同memory片子/参数时不需要重新编译. 根据这个需要修改了Clkrst_MemParm_DefaultGet, Clkrst_App_PrintAllCpu等函数. 原有batchswitch测试使用CLKRST_AUTOSWITCH_BATCH_RUN_BEFORE_AASP宏, 默认此宏不定义. 同时在clkrst模块加入batchswitch(do_clkswitchBatchSwtich())命令.
(2), 加入c_clk_pll2f2表示pll2 fout2, 当cpu,bus在pll2时, clock tree是
c_clk_pll2 -- c_clk_pll2f2 -- c_clk_cpu
`- c_clk_bus
在pll1时:
c_clk_pll1 -- c_clk_cpu
`- c_clk_bus
(3), sram切频流程(Clkrst_Drv_TriggerSwitch)有微调:
a, 切频时如果没有进入auto-entry self-refresh, 软件设置sdrc_cfg[9]=1, 使其进入.
b, sdrc_timinig[28:31]的auto self-refresh count设为0, 表示(0+1)*16=16cycles后进入self refresh, 避免由于sdrc周期发送auto-refresh导致dram无法进入self-refresh. 详见"10:11 2009-9-8"2-3)
(4), 调整Clkrst_Drv_SysInfo_Cmp: 区分xclk, pll1和pll2两个情况. 加入Clkrst_Drv_SysInfo_Cmp_ingoreVdec函数————不考虑vdec差异, 例如比较memory参数对应频点时不考虑vdec.
(5), 完善Clkrst_MemParm_Cpy(), 原来没有copy clkrst_pll_sdrc_adjAry, clkrst_pll_sdrc_adj和getSdrcRefresh.
(6), 调整Clkrst_Mem_GetCurBusMax, Clkrst_Mem_GetCurBusPreferedMax. 原来是单独定义一个数组保存不同memory的最大和最大推荐频率, 现在把这两个频率放到TMemoryInfo中. 数据更紧凑.
CVS log
Checking in bootloader/vc0830_main.c;
/doing/public/methodology/ic-arch-verif/fpga_verif/VERIFY/VC0830/VC0830/bootloader/vc0830_main.c,v <-- vc0830_main.c
new revision: 1.139; previous revision: 1.138
done
Checking in clkrst/app/clkrst_app.c;
/doing/public/methodology/ic-arch-verif/fpga_verif/VERIFY/VC0830/VC0830/clkrst/app/clkrst_app.c,v <-- clkrst_app.c
new revision: 1.45; previous revision: 1.44
done
Checking in clkrst/app/clkrst_app.h;
/doing/public/methodology/ic-arch-verif/fpga_verif/VERIFY/VC0830/VC0830/clkrst/app/clkrst_app.h,v <-- clkrst_app.h
new revision: 1.18; previous revision: 1.17
done
Checking in clkrst/app/clkrst_app_module_clock.c;
/doing/public/methodology/ic-arch-verif/fpga_verif/VERIFY/VC0830/VC0830/clkrst/app/clkrst_app_module_clock.c,v <-- clkrst_app_module_clock.c
new revision: 1.7; previous revision: 1.6
done
Checking in clkrst/app/clkrst_app_module_clock.h;
/doing/public/methodology/ic-arch-verif/fpga_verif/VERIFY/VC0830/VC0830/clkrst/app/clkrst_app_module_clock.h,v <-- clkrst_app_module_clock.h
new revision: 1.6; previous revision: 1.5
done
Checking in clkrst/app/clkrst_app_switch.c;
/doing/public/methodology/ic-arch-verif/fpga_verif/VERIFY/VC0830/VC0830/clkrst/app/clkrst_app_switch.c,v <-- clkrst_app_switch.c
new revision: 1.10; previous revision: 1.9
done
Checking in clkrst/app/clkrst_app_switch.h;
/doing/public/methodology/ic-arch-verif/fpga_verif/VERIFY/VC0830/VC0830/clkrst/app/clkrst_app_switch.h,v <-- clkrst_app_switch.h
new revision: 1.5; previous revision: 1.4
done
Checking in clkrst/basefunc/clkrst_basefunc.h;
/doing/public/methodology/ic-arch-verif/fpga_verif/VERIFY/VC0830/VC0830/clkrst/basefunc/clkrst_basefunc.h,v <-- clkrst_basefunc.h
new revision: 1.19; previous revision: 1.18
done
Checking in clkrst/driver/clkrst_drv.c;
/doing/public/methodology/ic-arch-verif/fpga_verif/VERIFY/VC0830/VC0830/clkrst/driver/clkrst_drv.c,v <-- clkrst_drv.c
new revision: 1.8; previous revision: 1.7
done
Checking in clkrst/driver/clkrst_drv.h;
/doing/public/methodology/ic-arch-verif/fpga_verif/VERIFY/VC0830/VC0830/clkrst/driver/clkrst_drv.h,v <-- clkrst_drv.h
new revision: 1.5; previous revision: 1.4
done
Checking in clkrst/driver/clkrst_drv_divider.h;
/doing/public/methodology/ic-arch-verif/fpga_verif/VERIFY/VC0830/VC0830/clkrst/driver/clkrst_drv_divider.h,v <-- clkrst_drv_divider.h
new revision: 1.4; previous revision: 1.3
done
Checking in clkrst/driver/clkrst_drv_system_info.c;
/doing/public/methodology/ic-arch-verif/fpga_verif/VERIFY/VC0830/VC0830/clkrst/driver/clkrst_drv_system_info.c,v <-- clkrst_drv_system_info.c
new revision: 1.5; previous revision: 1.4
done
Checking in clkrst/driver/clkrst_drv_system_info.h;
/doing/public/methodology/ic-arch-verif/fpga_verif/VERIFY/VC0830/VC0830/clkrst/driver/clkrst_drv_system_info.h,v <-- clkrst_drv_system_info.h
new revision: 1.6; previous revision: 1.5
done
Checking in clkrst/driver/clkrst_public_type.h;
/doing/public/methodology/ic-arch-verif/fpga_verif/VERIFY/VC0830/VC0830/clkrst/driver/clkrst_public_type.h,v <-- clkrst_public_type.h
new revision: 1.9; previous revision: 1.8
done
Checking in clkrst/memory/mem_config.c;
/doing/public/methodology/ic-arch-verif/fpga_verif/VERIFY/VC0830/VC0830/clkrst/memory/mem_config.c,v <-- mem_config.c
new revision: 1.9; previous revision: 1.8
done
Checking in clkrst/memory/mem_config.h;
/doing/public/methodology/ic-arch-verif/fpga_verif/VERIFY/VC0830/VC0830/clkrst/memory/mem_config.h,v <-- mem_config.h
new revision: 1.8; previous revision: 1.7
done
Checking in clkrst/memory/mem_mddr_micron.c;
/doing/public/methodology/ic-arch-verif/fpga_verif/VERIFY/VC0830/VC0830/clkrst/memory/mem_mddr_micron.c,v <-- mem_mddr_micron.c
new revision: 1.7; previous revision: 1.6
done
Checking in clkrst/memory/mem_pcddr_hynix.c;
/doing/public/methodology/ic-arch-verif/fpga_verif/VERIFY/VC0830/VC0830/clkrst/memory/mem_pcddr_hynix.c,v <-- mem_pcddr_hynix.c
new revision: 1.12; previous revision: 1.11
done
Checking in clkrst/memory/mem_sdram_samsung.c;
/doing/public/methodology/ic-arch-verif/fpga_verif/VERIFY/VC0830/VC0830/clkrst/memory/mem_sdram_samsung.c,v <-- mem_sdram_samsung.c
new revision: 1.7; previous revision: 1.6
done
Checking in clkrst/memory/mem_sdram_vimicro_BGA181.c;
/doing/public/methodology/ic-arch-verif/fpga_verif/VERIFY/VC0830/VC0830/clkrst/memory/mem_sdram_vimicro_BGA181.c,v <-- mem_sdram_vimicro_BGA181.c
new revision: 1.5; previous revision: 1.4
done
RCS file: /doing/public/methodology/ic-arch-verif/fpga_verif/VERIFY/VC0830/VC0830/clkrst/memory/mem_sdram_eorex.c,v
done
Checking in clkrst/memory/mem_sdram_eorex.c;
/doing/public/methodology/ic-arch-verif/fpga_verif/VERIFY/VC0830/VC0830/clkrst/memory/mem_sdram_eorex.c,v <-- mem_sdram_eorex.c
initial revision: 1.1
done
Checking in clkrst/subdir.mk;
/doing/public/methodology/ic-arch-verif/fpga_verif/VERIFY/VC0830/VC0830/clkrst/subdir.mk,v <-- subdir.mk
new revision: 1.24; previous revision: 1.23
done
Checking in clkrst/test/clkrst_test.c;
/doing/public/methodology/ic-arch-verif/fpga_verif/VERIFY/VC0830/VC0830/clkrst/test/clkrst_test.c,v <-- clkrst_test.c
new revision: 1.34; previous revision: 1.33
done
Checking in include/sys.h;
/doing/public/methodology/ic-arch-verif/fpga_verif/VERIFY/VC0830/VC0830/include/sys.h,v <-- sys.h
new revision: 1.58; previous revision: 1.57
done
Checking in ld_script/dram32M_4bank_dynamic.lds;
/doing/public/methodology/ic-arch-verif/fpga_verif/VERIFY/VC0830/VC0830/ld_script/dram32M_4bank_dynamic.lds,v <-- dram32M_4bank_dynamic.lds
new revision: 1.7; previous revision: 1.6
done
Checking in marb/bsdrc.h;
/doing/public/methodology/ic-arch-verif/fpga_verif/VERIFY/VC0830/VC0830/marb/bsdrc.h,v <-- bsdrc.h
new revision: 1.5; previous revision: 1.4
done
Checking in sdio/src/sdiodrv.c;
/doing/public/methodology/ic-arch-verif/fpga_verif/VERIFY/VC0830/VC0830/sdio/src/sdiodrv.c,v <-- sdiodrv.c
new revision: 1.104; previous revision: 1.103
done
后来有几个小的编译问题, 重新提交, 同时提交了上面的log(含CVS log), 此次CVS log如下:
/doing/public/methodology/ic-arch-verif/fpga_verif/VERIFY/VC0830/VC0830/Makefile,v <-- Makefile
new revision: 1.83; previous revision: 1.82
done
Checking in config.mk;
/doing/public/methodology/ic-arch-verif/fpga_verif/VERIFY/VC0830/VC0830/config.mk,v <-- config.mk
new revision: 1.115; previous revision: 1.114
done
Checking in clkrst/app/clkrst_app_switch.c;
/doing/public/methodology/ic-arch-verif/fpga_verif/VERIFY/VC0830/VC0830/clkrst/app/clkrst_app_switch.c,v <-- clkrst_app_switch.c
new revision: 1.11; previous revision: 1.10
done
Checking in clkrst/driver/clkrst_drv.c;
/doing/public/methodology/ic-arch-verif/fpga_verif/VERIFY/VC0830/VC0830/clkrst/driver/clkrst_drv.c,v <-- clkrst_drv.c
new revision: 1.9; previous revision: 1.8
done
2), 打包工具SpiScanMemPack
zhangjian, clkrst, clkswitch
1, 加入SV LQF282 mobile ddr micro的范例配置文件
2, 打包工具加入batchswtich info的版本号
Checking in SpiScanMemPackDlg.cpp;
/doing/public/methodology/ic-arch-verif/fpga_verif/VERIFY/VC0830/vc0830_sv_memscan_use_spi_eeprom/SpiScanMemPack/SpiScanMemPackDlg.cpp,v <-- SpiScanMemPackDlg.cpp
new revision: 1.13; previous revision: 1.12
done
RCS file: /doing/public/methodology/ic-arch-verif/fpga_verif/VERIFY/VC0830/vc0830_sv_memscan_use_spi_eeprom/SpiScanMemPack/batchswitch_info_SVLQFP282_MddrMicro.txt,v
done
Checking in batchswitch_info_SVLQFP282_MddrMicro.txt;
/doing/public/methodology/ic-arch-verif/fpga_verif/VERIFY/VC0830/vc0830_sv_memscan_use_spi_eeprom/SpiScanMemPack/batchswitch_info_SVLQFP282_MddrMicro.txt,v <-- batchswitch_info_SVLQFP282_MddrMicro.txt
initial revision: 1.1
done
RCS file: /doing/public/methodology/ic-arch-verif/fpga_verif/VERIFY/VC0830/vc0830_sv_memscan_use_spi_eeprom/SpiScanMemPack/batchswitch_info_SV_sdramSamsung.txt,v
done
Checking in batchswitch_info_SV_sdramSamsung.txt;
/doing/public/methodology/ic-arch-verif/fpga_verif/VERIFY/VC0830/vc0830_sv_memscan_use_spi_eeprom/SpiScanMemPack/batchswitch_info_SV_sdramSamsung.txt,v <-- batchswitch_info_SV_sdramSamsung.txt
initial revision: 1.1
done
5, 代码已提交. 用新代码实验EVB pcddrHynix和SV BGA282 mddrMicro. 如果pass打个tag. 同时完成文档.
6, 文档
(11:16 2010-3-30)已合并到notes(D:\VC0830\VC0830\clkrst), 见"11:18 2010-3-30"
"11:17 2010-3-30"end
7, 文档已发. 编译"me_sv_128m"pass. 代码已上传.
8, (13:40 2009-9-9)两个板子都是0908_19--0909_1330, 大约18小时.
EVB pcddrHynix(#7), 切频68780轮(7个频点)未死.
SV BGA282 mddr(BGA282: 80090403033, mddrMicro80090408045 底板80090319030), 切频169196轮(4个频点)未死.
保存代码.830代码,打包工具代码,打包工具.rar都放到"阶段性映像".
代码, 映像和文档位置: "D:\work\VC0830\SV\阶段映像和log\20090908_切频打包工具", 映像和文档在"切频和720p打包工具.rar"中.
9, 总结目前切频工作阶段性完成, 如果切频流程没问题估计代码不会有变化了. 目前切频需要注意: 一, sram返回前要查询切频前写入的memory magic正确, 如果提前返回可能会出错. 这个错误用jtag没法发现, 因为用jtag看时memory肯定已经稳定了. 二, 切频时保证无人访问dram, 目前通过检查是否进入自刷新保证dram无访问. 除此之外如果切频切死了都是memory不稳定造成的. 另外对于极限频率, 有可能出现静态可以, 动态不稳定的情况, 判断动态代码有无问题的方法是升压————如果升压后文档, 说明是频率极限, 不是动态切频问题.
有时间可以总结切频中遇到的问题, 总结后请dongliang帮我review.
0:39 2009-9-9
(19:53 2009-9-9)
Linux移植, VC0830, BGA282, VC0836移植分析, 与本组已有830移植比较; 文档
0, 总体浏览了836的移植, 将来需要一个函数一个函数看.
1, clock.c: 初始化830系统时钟, 相当于VC0830/bootloader/vc830_main.c中clock_init()的功能. 没有涉及Linux要求的clk结构体及其操作函数.\
2, vc0830.c: 830 board.
836的移植采用SOC与board分离的方法, 实际上除了goldfish都是这样的. 我们的830移植为了简化把SOC和board都放到了board-vc0830.c, 将来肯定是要分开的.
3, core.c: 描述830 SOC.
1), 值得注意的只有clock event没有clock source, 所以默认的jiffies作为clock source. clock event的feature包括CLOCK_EVT_FEAT_PERIODIC | CLOCK_EVT_FEAT_ONESHOT, 同时注意到vc0830_timer0_set_next_event直接返回0, 也就是没有设置下一次中断, CLOCK_EVT_FEAT_PERIODIC模式下不需要每次设置中断.
(1), 分析每个调用tick_setup_periodic()的函数.
A, tick_device_uses_broadcast() / tick_check_broadcast_device() / tick_do_broadcast_on_off() / tick_resume_broadcast() -> tick_broadcast_start_periodic() -> tick_setup_periodic()
B, tick_do_broadcast_on_off() -> tick_setup_periodic()
C, tick_notify()(reason == CLOCK_EVT_NOTIFY_ADD时, 表示新添clockevent) -> tick_check_new_device() -> tick_setup_device()-> tick_setup_periodic()
也就是说新加入每个clockevent时都会执行 tick_setup_periodic(), 对于CLOCK_EVT_FEAT_PERIODIC会调用 clock_event_device.set_mode进行CLOCK_EVT_FEAT_PERIODIC所需操作, 感觉是针对不同CLOCK_EVT进行不是设置. 对于CLOCK_EVT_FEAT_ONESHOT会执行第一次 clock_event_device.set_next_event(返回0表示成功, 836的移植是直接返回0)
D, tick_resume() -> tick_setup_periodic()
4, cp15.h: 开关中断, 开关cache, 读cp15等汇编. \todo 感觉这是通用函数, 为什么要这里实现呢?
5, devices.c: 注册了vc083x_device_usbgadget platform_device, 显然是后面的驱动会注册usb gadget driver.
6, nand.c: 注册nand设备. 等待zhicheng补充.
7, include
1), debug-macro.S: kernel lowlevel debug 所需的uart操作.
2), entry-macro.S: Low-level IRQ helper macros for VC0830 platforms.
8, driver/serial/vc0830_uart.c: 多数函数与我们类似, 只有方法多些东西:
vc0830_uart_startup()中注册了一个timer(handler vc0830_uart_timeout)用于发送,
vc0830_uart_timeout()在发送完成时(tr empty为真)调用vc0830_uart_transmit_chars()发送. 与我们相同的地方是在vc0830_uart_start_tx()中直接调用vc0830_uart_transmit_chars()发送字符. 由于830没有发送中断, vc0830_uart_transmit_chars()只能是一次发送完xmit中所有字符.
\todo 用time中断反复调用发送函数, 目的何在? 为了模拟发送中断, 还是为了及时发送?
9, 目录"drivers\mtd\nand\vc083x_nand"
zhicheng看了看, 发现基本是把830 nand代码copy过来.
17:40 2009-9-9
VC01600, SV, arm仿真器.
1, 以个人名义咨询了北京麦尔泰, 有BDI和code viser都支持CortexA8调试.
code viser是韩国公司做的, 据介绍对Linux和windowCE调试都支持, 当然也支持裸的硬件调试. 完整板工具(支持全系列arm)大约3000$, 可以选择不同包, 少选一些可能可以便宜一些. 下面是链接
http://www.bmrtech.com/products/jandd.htm
BDI由于使用GDB调试, 所以只支持裸硬件和Linux的调试.
2, 拿到了bdi和code viser的文档, 位置: "D:\work\Documentation\调试工具"
这两个工具都能调试Linux kernel, 对开发有一定帮助.
1), bdi可以调试裸硬件和Linux(通过GDB). 调试Linux使用gdb方式, 用起来比较方便, 可以用eclipse或insight等前端. 这种调试与我们调试qemu模拟器上运行的Linux kernel方式一样.
2), code viser使用自己的调试工具CVD, 据称支持Linux, winCE6.0等多种操作系统. 附件中有调试文档. 调试Linux时需要写脚本load映像, 指定source code命令. 调试winCE的文档介绍了调试bootloader(eboot), kernel, dll的方法. Lingming帮忙看看这样调试winCE石有用呢?
19:45 2009-9-9
Linux移植, uart, 文件系统, busybox, 今日进展, 本日工作总结, 2009年9月8日-2009年9月9日, 软件技巧, putty无法接收
1, (0908)拿到楼下836移植code, 和zhicheng一起分析了与现有我们830移植的差异. 具体差异参见文档"Linux移植, VC0830, BGA282, VC0836移植分析, 与本组已有830移植比较"
1), vmlinux/Image可以跑起来, zImage跑不起来. 原因未知. \todo 需要问楼下同事.
开始以为是自己编译问题, 后来发现是zImage问题. 编译器使用的是goldfish arm-eabi-gcc 4.2.1
2), 跑836kernel时文件系统有问题, 启动后无法输入.
从配置文件名称看836基本照搬android的文件系统
2, 9月7日的串口无法输入问题其实是由于putty无法接收造成的. 有时串口出现的乱码会导致putty认为接收到错误控制字符关闭串口接收. 重新打开putty问题解决. 0909晚上排查时, 更换了板子和串口线都不行, zhangjian突然想到是putty问题, 原来做切频时也遇到过.
19:45 2009-9-9
Linux移植, uart, 文件系统, busybox, 今日进展, 本日工作总结, 2009年9月10日
1, 上午会议
1), 简单介绍了最近Linux移植进展. 争取以后这周都开会讲讲. 下周计划是FanXiaoFan讲PCI/PCI-e.
2), 目前移植仍存在的问题: sleep(1)会死(也可能是时间过长); shell中回显速度很慢, 考虑用楼下的timer方式.
3), 下一步计划: zhangpu移植framebuffer. 以后计划是做android平台.
2, 今日进展:
1), 串口回显慢有改进:
昨天实验时830的tx_empty是直接返回的0, 所以uart_wait_until_sent是超时退出的. 今天把tx_empty改为查询发送状态. 现在速度正常很多, 但还是感觉有点慢.
另外据zhicheng实验结果, 836移植中uart的timer对回显速度没有影响.
2), zhangpu实验simple platform device. 注册使用platform_driver_register, platform_device_alloc和platform_device_add; 注销使用platform_device_unregister, platform_driver_unregister. 不能用platform_device_register, 因为后者不会注册platform_device的release.
3, 明天计划:
1), SVN上传. 我自己跑一遍SVN上的代码.
2), 解决sleep问题.
15:50 2009-9-10
VC0830, SV, clkrst, clkswitch, 会议记录, 切频流程已给YouHai, Jiangbo(根据现有流程修改databook)
1, pll1_sdrc_adj中xclk_path如何配置? 配置是否影响pll1?
不影响. 配置xclk时pll1_sdrc_adj只能修改3,11,15. 配置pll1时相反。
加入了Clkrst_GetXclkPhase, Clkrst_SetXclkPhase, 修改了Clkrst_GetPll1SdrcAdjClk, Clkrst_SetPll1SdrcAdjClk. 等liuchuan邮件修改.
2, pll2最高614.4. 所以pll2 cpu,bus 只保证308/4.
3, youhai使用cache的原因是sram用于视频软解码加速.
4, 给youhai, jiangbo发code, 并做简要说明(着重说明与databook不同点)
邮件"答复: 在讨论下文档和工具的结构"20090910_1811
Hi, jiangbo
如下是目前切频流程, 及其与databook的差异
Hi, youhai:
用红色表示与之前sram切频流程的差异
clkrst\app\clkrst_app_switch.c描述了切频api, 其中"Clkrst_SwitchPll12Pll1Base()"是核心切频函数. sram切频是Clkrst_Drv_TriggerSwitch()(clkrst\drv\clkrst_drv.c).
目前切频流程与databook差异主要是sdrc_mode(0x60011004)没有shadow寄存器, 所以不能在sdram中配置. 例如放到sram中切频流程如下:
//1, 在sdram中写入magic number, 返回sdram前读取sdram三个magic number, 正确
//后返回, 目前发现EVB eorex_6 sdram 如果没有确定memory正确直接返回, 切频
//不稳定.
g_clkrst_Switch_magic[0] = CLKRST_SWITCH_MAGIC1;
g_clkrst_Switch_magic[1] = CLKRST_SWITCH_MAGIC2;
g_clkrst_Switch_magic[2] = CLKRST_SWITCH_MAGIC3;
//2, trigger切频
if ( CLK_NORMAL == Clkrst_GetPllSwitch() ) {
Clkrst_SetNormal2Bypass();
} else {
Clkrst_SetBypass2Normal();
}
//3, 为了设置sdrc_mode(0x60011004), 需要先禁止sdrc shadow寄存器
Sdrc_ClkSwitchEnd();
//4, 设置sdrc_mode, 设置sdrc_mode时必须保证dram无访问(如果dram进入self
//refresh说明无访问)
//1), 为了避免sdrc刷新dram造成dram无法进入self refresh, 把self refresh
//count设为最小(=(0+1)*16=16cycles)
Sdrc_GetSdrcTiming(Clkrst_Sdram2SramVal(&g_clkrst_sdrc_timing_Tase_bak));
Sdrc_SetSdrcTiming(Clkrst_Sdram2SramVal(&g_clkrst_sdrc_timing_Tase_bak) & 0x0fffffff );
//2), 打开自动进入self refresh
Sdrc_EnableAutoEnterSelfRefresh();
//3), 查询是否进入self refresh
while( 1 != Sdrc_GetStatus() );
//4), 关闭并确认退出self refresh
Sdrc_DisableAutoEnterSelfRefresh();
Sdrc_SendCmd_SLFRSHX();
while( 0 != Sdrc_GetStatus() );
//5), 修改sdrc_mode, 发送MRS, EMRS更新sdrc_mode到dram内部寄存器. EMRS不是每
//个片子都有. sdrc_cfg[9]==1表示有EMRS, sdrc_cfg是rom bootloader利用512 info
//配置的.
Sdrc_SetSdrcMode(Clkrst_Sdram2SramVal(&g_clkrst_sdrc_mode));
Sdrc_SendCmd_MRS();
if ( Sdrc_GetSdrcCfg_EMRSEnable() ) {
Sdrc_SendCmd_EMRS();
}
//6), linchuan建议的nop
asm volatile (
"nop;"
"nop;"
"nop;"
"nop;"
"nop;"
);
//7), 打开自动进入self refresh
Sdrc_EnableAutoEnterSelfRefresh();
//8), 恢复sdrc_timing
Sdrc_SetSdrcTiming(Clkrst_Sdram2SramVal(&g_clkrst_sdrc_timing_Tase_bak));
//5, 准备返回sdram, 返回前一定要保证切频前写入的三个magic number正确.
while ( CLKRST_SWITCH_MAGIC1 != g_clkrst_Switch_magic[0]
&& CLKRST_SWITCH_MAGIC2 != g_clkrst_Switch_magic[1]
&& CLKRST_SWITCH_MAGIC3 != g_clkrst_Switch_magic[2] );
// clkrst_drv_delay_400000000cycle11_12_13_14();
//6, 返回sdram
asm volatile (
"mov r1, %0;"
"nop;"
"nop;"
"nop;"
"nop;"
"nop;"
"ldr pc, [r1];"
: \
: "r" (Clkrst_Sdram2SramAddr(&g_clkrst_pc_bak)) \
: "cc", "r1" \
);
17:19 2009-9-10
Linux移植, arm debug, 开发工具, JTAG与调试环境列表, 常用的JTAG支持列表, 常用调试环境支持列表
LiaoZhiCheng邮件"JTAG与调试环境列表"20090910_1426
常用的JTAG支持列表：
ARM7 ARM9 ARM11 CORTEX-M3 CORTEX-A8 CORTEX-A9
Multi-ICE √ √ × × × ×
JLINK V6 √ √ × × × ×
JLINK V7 √ √ √ √ × ×
ULINK 2 √ √ × √ × ×
RealView ICE 2 √ √ √ √ √ ×
RealView ICE 3.3 √ √ √ √ √ √
BDI3000 √ √ √ √ √ ×
Trace-32 √ √ √ √ √ √
code viser √ √ √ √ √ ?
常用调试环境支持列表：
ARM7 ARM9 ARM11 CORTEX-M3 CORTEX-A8 CORTEX-A9
AXD 1.2 √ √ √ × × ×
RVD 1.8 √ √ √ × × ×
RVD 3.0 √ √ √ √ √ ?
RVD 4.0 √ √ √ √ √ ?
10:05 2009-9-11
Linux移植, uart, 文件系统, busybox
1, svnserver说明
1), 先说明一下目前的svn目录:
svn server位于: 服务器(10.0.26.35)的/svn, 目前有如下几个repo:
goldfish: 是goldfish(2.6.27)注释版本, 用于早期学习;
linux-2.6.27.26: 早期830 linux移植版本, 在qemu realview模拟器上kernel打印信息不全. 暂时不用.
vmc: 目前830 linux移植版本, 版本2串口ok. (版本1应该也是ok的, 当时应该是pc的putty有问题造成串口无法输入)
linux-bootloader: zhicheng写的linux bootloader, 未完成.
2), svn访问权限信息位于repo/conf目录, 例如/svn/vmc/conf. 其中
svnserve.conf: 总的配置文件, 这里指明了用户在authz文件, 密码在passwd文件
authz: 用户访问控制
passwd: 密码文件, 为了简单使用的是明码.
2, 昨天串口回显速度还是有些慢, zhicheng在串口接收部分加入打印信息, 发现在所有串口接收结束后, 有明显延迟后才有回显, 感觉不是串口接收的问题. 从busybox打出的信息看串口发送也没有延时. 这样先kernel出问题的可能性不大, 感觉可能是busybox造成的. 会不会是busybox回显时有延时造成的呢? 这样其实和sleep问题是同一问题了. 所以分两个方向:
1), 先实验sleep: 在helloworld的usleep前后打印信息.
中午实验发现睡眠时间很长.
2), 暂未分析出结果.
3, uClibc-20090911.tar的usleep
"libc/unistd/usleep.c""
#if defined __USE_BSD || defined __USE_POSIX98
#if defined __UCLIBC_HAS_REALTIME__
/*libc_hidden_proto(nanosleep) need the reloc for cancellation*/
int usleep (__useconds_t usec)
{
const struct timespec ts = {
.tv_sec = (long int) (usec / 1000000),
.tv_nsec = (long int) (usec % 1000000) * 1000ul
};
return(nanosleep(&ts, NULL));
}
#else /* __UCLIBC_HAS_REALTIME__ */
/* libc_hidden_proto(select) */
int usleep (__useconds_t usec)
{
struct timeval tv;
tv.tv_sec = 0;
tv.tv_usec = usec;
return select(0, NULL, NULL, NULL, &tv);
}
#endif /* __UCLIBC_HAS_REALTIME__ */
#endif
1), 如果用select方式实现, 对应系统调用 do_select
大致分析调用过程, 可以看到do_select通过软定时器实现, 所以最小精度是一个tick.
do_select() -> schedule_timeout() -> __mod_timer()
2), 如果用nanosleep实现;
即对应系统调用 do_nanosleep,
do_nanosleep() 使用高精度定时器实现. 暂时不详细分析. 大致过程如下, 可以看出后面调用了clock_source_event的set_next_event, 同时看到max_delta_ns根据clock_source_evnet的max_delta_ns, min_delta_ns对传入的定时时间round.
set_next_event
目前知道的调用关系:
do_nanosleep() -> hrtimer_start() -> hrtimer_raise_softirq()
hrtimers_init()通过open_softirq注册run_hrtimer_softirq为hrt的软中断处理函数.
run_hrtimer_softirq() -> run_hrtimer_pending() -> hrtimer_reprogram() -> tick_program_event() -> tick_dev_program_event() -> clockevents_program_event() -> clock_event_device.set_next_event
4, updata_wall_time()的__do_div64提示除0
查找发现 update_wall_time() -> change_clocksource() -> clocksource_calculate_interval() -> do_div() -> __do_div_asm() -> __do_div64
发现clocksource的multi是0. 修改后可以正常挂载文件系统.
但是helloworld中sleep 1ms会很长时间.
5, 分析sleep
uClibc中sleep()定义__UCLIBC_HAS_REALTIME__时通过nanosleep实现. 未定义时通过alarm实现.
6, review timer代码
1), 发现有些地方写的timer0, 有些地方写的timer1. 中断注册的是timer0. 统一改为timer1;
2),
.features = CLOCK_EVT_FEAT_PERIODIC | CLOCK_EVT_FEAT_ONESHOT,
写成了
.features = CLOCK_EVT_MODE_PERIODIC | CLOCK_EVT_FEAT_ONESHOT,
7, (21:20 2009-9-11)
1), 从上面结果看, 之前去掉CLOCK_EVT_FEAT_ONESHOT不能用的原因是CLOCK_EVT_FEAT_PERIODIC设置错误, 而且初始化设置的timer1, 中断注册的是timer0.
考虑到sleep涉及东西较多, 下周打算分开分析, 用get_timeofday判断时间是否正确, 如果正确说明就需要看sleep其他问题.
2), 今天的另一结果是修改了clocesource和clock_event_device的multi的计算方式. 原来以为这里造成sleep有问题, 后来发现不是.
21:27 2009-9-12
项目, 工作总结, 本周总结, 9月工作总结, 20090907-20090913
1, 主要工作内容:
1), Linux移植: 2), 3)的剩余时间, 大于3天.
2), 上周工作总结: Linux移植日志和个人周工作总结. 3小时.
3), 接上周完成切频打包工具测试. 1.5天.
2, 主要问题:
1), 上周工作总结应该放在上周完成, 放在本周影响效率.
21:40 2009-9-12
Linux移植, uart, 文件系统, busybox, 今日进展, 本日工作总结, 2009年9月11日
1, 09/11: review timer代码, timer代码统一使用timer1. 使用clocksource和clock_event_device, 且二者的multi由函数利用shift计算得到. 暂时没有解决现存问题.
21:43 2009-9-12
Linux移植, uart, timer, 文件系统, busybox, Linux移植进展, 工作总结, 本周工作总结, 2009年9月7日--2009年9月12日
1, 从本周开始记录日工作日志, 所以周工作日志不再详细说明问题, 只写出本周outline和下周计划.
2, 本周最大进展是830 linux终于可以启动到shell. 遗留问题是sleep时间超长; shell回显速度慢.
3, 下周计划:
1), 从目前看uart没有太大问题. 下周希望相信分析timekeeping, timer代码. 解决现有830问题. 如果单分析自己830代码无法解决问题, 可以对比楼下836移植.
注: 楼下836移植半新不旧, 而且并不规范, 看不规范的代码其实帮助不是很大, 所以并不希望过多参考楼下代码, 只是作为bakcup.
2), 从目前830 uart和timer代码情况看, 在code初步调试通过后尽早review code很有好处. 如果zhangpu framebuffer完成, 希望尽快review.
14:05 2009-9-14
时间table
1, 上午: fanxiaofan, PCI介绍.
14:16 2009-9-14
网址, arm, SOC, IP
http://infocenter.arm.com/help/index.jsp, arm infomation center, 包括
1, PrimeCell peripherals(各种IP, GPIO, CLCD, DMAC等等),
2, Development boards: arm realview, vertatile, intergrator cp等等开发板.
14:00 2009-9-14
Linux移植, uart, time/timer, 文件系统, busybox, 今日进展, 本日工作总结, 2009年9月14日
1, 今日计划
1), zhicheng实验 836移植的timer.<DONE>
2), zhangjian研究realview timer.<DOING>
3), 把下载的文档放到36. <DONE>
2, 下载了qemu模拟器中使用的arm soc及其ip的datasheet. "\\10.0.2.36\sqmshare\Share\linux\doc\soc datasheet\arm_soc"
kernel代码中arch\arm\mach-realview\realview_eb.c对应的SOC是realview/DUI0303D_emulation_baseboard_user_guide.pdf
15:47 2009-9-14
Linux移植, uart, time/timer, 文件系统, busybox
1, tick的通知链使用了RCU
官方介绍: http://lse.sourceforge.net/locking/rcupdate.html
以下介绍自: Linux\doc\kernel\RCU(Read-Copy Update)介绍.txt
自: http://blog.chinaunix.net/u1/55599/showart_1101095.html
RCU(Read-Copy Update),对于被RCU保护的共享数据结构，读者不需要获得任何锁就可以访问它，但写者在访问它时首先拷贝一个副本，然后对副本进行修改，最后使用一个回调（callback）机制在适当的时机把指向原来数据的指针重新指向新的被修改的数据。这个时机就是所有引用该数据的CPU都退出对共享数据的操作。
RCU实际上是一种改进的rwlock，读者几乎没有什么同步开销，它不需要锁，不使用原子指令，而且在除alpha的所有架构上也不需要内存栅（Memory Barrier），因此不会导致锁竞争，内存延迟以及流水线停滞。不需要锁也使得使用更容易，因为死锁问题就不需要考虑了。写者的同步开销比较大，它需要延迟数据结构的释放，复制被修改的数据结构，它也必须使用某种锁机制同步并行的其它写者的修改操作。读者必须提供一个信号给写者以便写者能够确定数据可以被安全地释放或修改的时机。有一个专门的垃圾收集器来探测读者的信号，一旦所有的读者都已经发送信号告知它们都不在使用被RCU保护的数据结构，垃圾收集器就调用回调函数完成最后的数据释放或修改操作。 RCU与rwlock的不同之处是：它既允许多个读者同时访问被保护的数据，又允许多个读者和多个写者同时访问被保护的数据（注意：是否可以有多个写者并行访问取决于写者之间使用的同步机制），读者没有任何同步开销，而写者的同步开销则取决于使用的写者间同步机制。但RCU不能替代rwlock，因为如果写比较多时，对读者的性能提高不能弥补写者导致的损失。
2,
1), 使用楼下836移植没问题
2), 我们移植代码去掉clocksource也没问题.
3), 我们的clocksource是timer1, 但是timer1同时也用做tick中断, 而且是满清的. 不是连续计数的.
所以把timer0用于tick timer 中断. timer1用于clock source read.
10:34 2009-9-15
(12:42 2009-9-15)
Linux移植, uart, time/timer, 文件系统, busybox, 今日进展, 本日工作总结, 2009年9月15日
1, 今日计划, 本周计划:
1), 为driver提供开发环境
(1), 注释busybox多余注释. zhicheng, zhangjian
(2), busybox上传SVN
(3), 做打包工具, 加CONFIG_VMC保证不影响其它平台kernel使用, zImage放到0x0地址不能启动问题暂时绕过. <zhicheng>
(4), 打包工具完成后写内核, busybox编译使用文档.
2), 开始详细分析time机制, 包括time,timer,tick,用户空间调用方法等. zhicheng, zhangjian. 计划本周完成.
(1), 疑问: 为什么原来timer.c不能用呢? 感觉除了multi计算不正确, 没什么大问题. zhicheng计划实验.
3), 分析uart,tty,console机制. 希望尽快完成.
4), 利用楼下836移植尝试usb net. 下周
5), 下午与aiguo讨论了最近工作安排
1-2周内完成linux移植分析(包括timer, uart, irq, memory等), 可能会被arm11开发环境这个事情打断.
2, memory.h(arch\arm\include\asm)中不能使用"//"注释. 只能使用"/**/"注释
编译vmlinux.lds时会include memory.h, arm ld链接时如果遇到//会提示错误.
我们的内核编译vmlinuxr.lds如下:
arm-none-linux-gnueabi-gcc -E -Wp,-MD,arch/arm/kernel/.vmlinux.lds.d -nostdinc -isystem /usr/src/embedded2/toolchain/arm-2009q1/bin/../lib/gcc/arm-none-linux-gnueabi/4.3.3/include -D__KERNEL__ -Iinclude -I/usr/src/embedded2/kernel/vmc/arch/arm/include -include include/linux/autoconf.h -mlittle-endian -Iarch/arm/mach-vmc/include -DTEXT_OFFSET=0x00008000 -P -C -Uarm -D__ASSEMBLY__ -o arch/arm/kernel/vmlinux.lds arch/arm/kernel/vmlinux.lds.S
vmlinux.lds.S 会 include asm/memory.h
vmlinux.lds详细分析见"vimicro_Linux移植文档"4-11-1
3, 今日进展:
1), 内核可以正常挂载文件系统, timer, uart简单试用正常.
2), 完成830内核和文件系统文档初稿
4, 目前问题
1), 830 timer移植为什么原来的不能用, 需要分析.
2), busybox是静态编译, 需要实验busybox是动态链接能否使用, 至少要实验应用程序能否使用动态库.
14:13 2009-9-15
Linux移植, VC0830, merge goldfish注释到现有vmc linux移植, svn, 项目文档, qemu
1, svn log, 使用英文避免乱码, 目前版本是7.
code has been tested in 830 BGA282+sdramSamsung board ( using vc0830_defconfig ) and qemu realview simulator ( using realview_defconfig ).
1), merge comment in goldfish kernel to vmc kernel souce tree
(1), dir: arch/arm, drivers/mtd, drivers/serial