2008-03-12 02:15:10 about PATA for BF54X
hua zhu (CHINA)
Message: 52359
hi,
as we know, the data bus for PATA on BF548EZKIT is wired to EBIU, and it's well supported by 2008R1 uClinux dist.
but if wired to ePPI0, is it supported by current uClinux driver? and will this bring significant performance raise?
pls advise, thanks.
QuoteReplyEditDelete
2008-03-12 02:51:26 Re: about PATA for BF54X
Sonic Zhang (CHINA)
Message: 52361
Don't know what do you mean by wire ATAPI data bus to ePPI0. Current driver only support ATAPI controll on BF548.
QuoteReplyEditDelete
2008-03-12 03:27:57 Re: about PATA for BF54X
hua zhu (CHINA)
Message: 52362
thx sonic and sorry for my vague expression.
ATAPI in BF54XEZKIT connects its data bus to EBIU data(multiplexed with EBIU data bus), and this is considerred to be poor in performance.
and another way is to connect ATAPI data bus to ePPI0(multiplexed with ePPI0), hope this may improve performance, but wonderring whether this is supported by the driver?
and would you kindly give a brief throughput test result on SATA harddisk?
as my test on the BF548EZKIT using Parallel ATA harddisk, it's max to 6MB , and does this mean a max 3MB/s for SATA?
pls advise.
QuoteReplyEditDelete
2008-03-12 03:35:33 Re: about PATA for BF54X
hua zhu (CHINA)
Message: 52363
and one more question :=)
it's said in the doc wiki, this driver support UDMA mode(10MB/s) and PIO mode, but how to set to UDMA mode?
thanks.
QuoteReplyEditDelete
2008-03-12 03:37:09 Re: about PATA for BF54X
hua zhu (CHINA)
Message: 52364
QuoteReplyEditDelete
2008-03-12 03:38:34 Re: about PATA for BF54X
hua zhu (CHINA)
Message: 52365
QuoteReplyEditDelete
2008-03-12 03:38:47 Re: about PATA for BF54X
Sonic Zhang (CHINA)
Message: 52366 UDMA is the default mode.
QuoteReplyEditDelete
2008-03-12 03:49:13 Re: about PATA for BF54X
Sonic Zhang (CHINA)
Message: 52367
I still can't understand how you can change the data bus of the ATAPI controller? It connect to the EBIU Async controller and share the bus with NOR, NAND and SRAM, which has nothing to do with the DDR controller.
QuoteReplyEditDelete
2008-03-12 03:56:26 Re: about PATA for BF54X
Michael Hennerich (GERMANY)
Message: 52369
Sonic,
I get up to 12MB/s on a BF537 without ATAPI/IDE controller by just using PIO mode and IDE drive connected directly to the Async Memory Bus. So I think there must be something wrong with our BF54x PATA driver!
-Michael
QuoteReplyEditDelete
2008-03-12 03:58:45 Re: about PATA for BF54X
hua zhu (CHINA)
Message: 52370
thanks sonic.
and about the data bus multicoplexing is from the datasheet, and no test done but the EZKIT.
and if UDMA is default mode, but the performance test is poor.
test BF548EZKIT using 2008R1, same config as http://docs.blackfin.uclinux.org/doku.php?id=blackfin_libata_pata_atapi_driver
using the PATA harddisk shipped with BF548EZKIT, bus info as below,
Compiled for ADSP-BF548 Rev 0.0
Blackfin Linux support by http://blackfin.uclinux.org/
Processor Speed: 525 MHz core clock and 131 MHz System Clock
mount /dev/sda1 /mnt/disk
time dd if=/dev/zero of=/mnt/disk/64MB bs=8192 count=8192
8192+0 records in
8192+0 records out
real 0m 31.58s
user 0m 0.11s
sys 0m 15.02s
it's only about 2MB/s
pls advise.
QuoteReplyEditDelete
2008-03-12 05:32:25 Re: about PATA for BF54X
Sonic Zhang (CHINA)
Message: 52381
The registered based ATA access mode is much faster than ATAPI protocol based ATA access mode. On bf537 the IDE driver reads/writes IDE registers in FPGA directly. On bf548 the ATAPI driver can only send/receive ATAPI messages through the ATAPI controller. Each reading/writing to the IDE register is wraped in several consequent ATAPI messages, which is slower and low efficiency. Register based ATA access mode is not supported in bf548. I talked with Austin hardware team about this issue last week.
QuoteReplyEditDelete
2008-03-12 06:04:14 Re: about PATA for BF54X
Michael Hennerich (GERMANY)
Message: 52384 Sonic,
I know we talked about this. However I think this can't be the only reason for an expected theoretical 66/33 MB/s throughput and 2MB/s. For me without looking at things, this sounds like we are not really using the capabilities of transfering multiple blocks by one command sequence.
This sounds like we are just doing PIO like accesses with the difference of transfering 512bytes by DMA.
-Michael