Difference between revisions of "Talk:10349"

Revision as of 09:52, 23 April 2008

About the plex panel for developer case: why do it transparent ? Is where a special reason ? It's not very good for image quality to have light inside the case. --Polto 11:36, 14 October 2007 (GMT)

Transparent? Why? Is it written anywhere?--Andrey.filippov 16:29, 14 October 2007 (CDT)

Yep, in 10349#Body_of_camera_for_developers --Polto 08:55, 15 October 2007 (GMT)

I looked at the images only, did not read the text. You are right there is no sense to have transparent cover - it will allow stray light to reach the sensor.--Andrey.filippov 03:10, 15 October 2007 (CDT)

No problem, we can use black plex. --dimon 21:11, 16 October 2007 (CDT)

Will the RS323 socket fit in the camera on top of both 10353 & 10349 ? --Polto 03:45, 1 November 2007 (GMT)

Should be yes. I measure distance between PCB of 10349 with 10353 to top of cover on 3D model. This is 11.5 mm. For common socket of RS232 this distance is good.

That is my comment. --dimon 22:17, 31 October 2007 (CDT)

Are these boards available for purchase or testing? --Ekratzer 15:51, 12 November 2007 (CST)

Yes, we just do not have our costs (and so the price) ready yet.

Andrey

I am trying to use CF + DMA on 10353 boards. I have tried many CF cards and they work fine under normal PIO modes, but not with DMA, even when tweaking parameters with hdparm. I have also found that some hard drives work with DMA, and some do not, leading me to believe that maybe there is some CF type that will work. Has anybody successfully use CF + DMA on the 353's ETRAX FS?

--Ekratzer 11:41, 28 January 2008 (CST)

That is very interesting. Can you please provide links to the exact circuit diagrams how you connect CF cards as well as to the source code you are using?--Andrey.filippov 13:08, 28 January 2008 (CST)

Andrey, I have uploaded our circuit diagram to rz_353_cf_interface.pdf As far as source code, we simply have a script that runs as last part of runlevel 3. It disables DMA (/sbin/hdparm -m 0 -c 1 -d 0 /dev/hda) and mounts /dev/hda1 on the filesystem. If we do not disable DMA, then the kernel just endlessly loops on dma timeouts when we try to access the CF. --Ekratzer 17:06, 29 January 2008 (CST)

It seems the problem with the your board is the lack of pullup/pulldown resistors on the INTRQ, DMARQ, IORDY lines.
 Those resistors are intentionally omitted on the 10353 board - the same I/O lines can be used for different purposes,
not just the IDE port.
 Hmm. DMARQ and DMACK are not shown on your diagram at all. Without the pulldown resistor on the DMARQ line
the 353 camera software will not initialize IDE driver, it uses it to determine that IDE capable add-on board
is attached to the 10353--Andrey.filippov 17:55, 18 February 2008 (CST).

Hmm, ok. I had disabled the check for _353_io_board_present in ide-cris.c to get past this problem (no pull down in DMARQ.)  --Ekratzer 07:22, 25 February 2008 (CST)

I see, thank you. By the end of the week I should have all the components for the 10369 board and I will put it together ans start testing with the CF cards (and SATA also). Did you try different brands/models? --Andrey.filippov 17:41, 29 January 2008 (CST)

I have tested with a variety of Transcend and Kingston CF, ranging from 512MB to 8GB, and speed ratings from 45x to 266x. I have also tested 2 hard drives, both Hitachi Travelstar. Model #HTS541040G9AT00 works well with DMA (over 15MB/s sustained write throughput with little CPU load), and model #HTC424020F7AT00 behaves the same as the CF (no DMA.) I have tested all these CF and hard drives on 5 of our CF interface boards, with results being the same for each. Interesting note, the kernel always detects and tries to enable DMA in cris_ide_init(), regardless of "ide=nodma" init option. It times out once after about 8 seconds, and then I can disable DMA and mount normally with PIO modes. --Ekratzer 14:12, 30 January 2008 (CST)

Also, I forgot to mention that I have also tried a couple IBM 4GB CF microdrives, with results being the same (no DMA.) --Ekratzer 14:18, 30 January 2008 (CST)

I see. Hope to have some results with the 10369 next week and see if I'll get the same problem. So far I tried several HDDs (no CF yet) and they worked fine (to be honest I even do not know if the DMA is enabled) - the recording speed for large files was around 15MB/s. With the 10369 I'll get there with the oscilloscope and add some "pritnk()" to the driver - I believe it should work faster.--Andrey.filippov 15:08, 30 January 2008 (CST)

I tried some CF card (QMemory 16GB) with 10369 (SATA HDD works just fine) and did find a problem with DMA. The CF card releases DMARQ after transferring just 1024 bytes (512 words) and does not reassert it when asked for 16 sectors to read during initialization. That leads to DMA timeout.

To fix it we need to limit number of sectors that are requested in a single DMA command.

--Andrey.filippov 04:39, 17 February 2008 (CST)

More details on the QMemory 16GB CF card. When that data is read using DMA (and the card reports it has it) the data transferred (until the CF drops DMARQ forever) is always 1024 bytes (2*512) - equal to the reported buffer size. That 1024 does not depend on the number of sector requested - it can be 1 (so 512 bytes were expected) or >2 (i.e. 16) - still DMA dies after 1024 bytes. Next problem - this CF card does not assert INTRQ after the READ DMA, and the driver reies on it to finish READ DMA command (that IRQ is required by the ATA specifications). I tried to tweak other parameters, like multsect with SET MULTIPLE MODE (it is designed fro READ MULTIPLE only) - still no interrupts at the end of READ DMA command.

I just ordered a bunch of different brands CF cards to test, if they will exhibit similar problems (CF+DMA shows multiple problems in Google search) the solution will be to add interrupt on the DMA (internal processor DMA, not ATA DMA) that will trigger after ETRAX FS receives requested amount of data in addition to ATA interrupts (derived from the INTRQ signal of the ATA bus) and limit number of sectors during a single READ DMA command. It will require changes in both ide-cris.c and higher level ide driver, as the current one does not rely on internal DMA interrupt, only on the ATA one.--Andrey.filippov 14:48, 18 February 2008 (CST)

Opening the CF card revealed SM222TF controller chip, same as for the card described here. It claims to support DMA, but the READ DMA/WRITE DMA commands are missing in the table of supported ones.

Will using the processor DMA instead of ATA require any changes to the circuit? If so, we can implement and test any changes. We will be making changes to fix INTRQ, DMARQ, IORDY, and DMACK lines shortly. --Ekratzer 08:05, 25 February 2008 (CST)

Interesting page for CF statistics. Shows which cards support DMA/PIO/etc: CARDSPEED - Card Readers and Memory Cards --Ekratzer 09:19, 25 February 2008 (CST)

Another card Transcend 32GB has SM223TF inside - exactly the same problem. Technical support from the chip manufacturer stopped replying my emails after I described the problem. They just mentioned that "they had some DMA problems with older firmware" :-( --Andrey.filippov 13:29, 7 April 2008 (CDT)

I am trying to move away from CF for our next board revision, since we cannot spare CPU for PIO mode transfers anymore. I have found some smaller IDE solid-state flash drives that have similar storage density to CF, like this drive from Transcend: 1.0" IDE SSD. I will be ordering and testing on the bench soon.. will post results here --Ekratzer 15:10, 22 April 2008 (CDT)

I opened another CF card (32GB Transcend) - it had SM223 controller - same problem. So far the only one that we tried and that works with DMA is Sandisk Extreme(R) III 2.0GB --Andrey.filippov 12:48, 23 April 2008 (CDT)