Difference between revisions of "Talk:10349"

Revision as of 12:48, 18 February 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)

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)