[meta-freescale] about freescale dvd-rom
lianjf at ava.com.cn
lianjf at ava.com.cn
Tue Aug 19 02:11:34 PDT 2014
Hi ,
As to the dvd-rom on freescale arm board,there is something more to talk about:the failure of burning of dvd-rom via sata-sata,it fails at SCSI-passthrough for DVD drives via ioctl(SG_IO).And the usb-sata connected dvd-rom doesnot meet this problem.
The details about SCSI-passthrough for DVD drives via ioctl(SG_IO) is from the author of burning tool,whose mail is bug-xorriso at gnu.org.
-----------------------------------------------------------------------------------------------------------------------------------------------------
I am upstream developer of libburn, which on Linux uses
ioctl(SG_IO) to perform SCSI transactions with DVD drives.
Lian jianfei experiences problems with these transactions,
but only on the Freescale ARM system, not on Linux systems
based on i386 or amd64 processors.
I would like to help my user to reach success. But my
knowledge of SCSI passthrough ends at the code part
where the transaction request enters the Linux elevator.
Needed would be an expert who can find the decisive differences
between SATA on i386 and SATA on ARM.
Lian jianfei and me are ready to do experiments and to provide
further details (of which we did not think now).
Symptoms are:
Some SCSI commands get implausible replies and some even get the
same reply bytes as the previous different command. I have a log
of the transactions on the user's machine.
At some point this leads to memory management corruption:
malloc.c:3096: sYSMALLOc: Assertion `(old_top == (((mbinptr) (((char *) &((av)->bins[((1) - 1) * 2])) - __builtin_offsetof (struct malloc_chunk, fd)))) && old_size == 0) || ((unsigned long) (old_size) >= (unsigned long)((((__builtin_offsetof (struct malloc_chunk, fd_nextsize))+((2 * (sizeof(size_t))) - 1)) & ~((2 * (sizeof(size_t))) - 1))) && ((old_top)->size & 0x1) && ((unsigned long)old_end & pagemask) == 0)' failed.
Valgrind finds no sins in userspace which would explain this.
But it crashes too with corruption of its own memory management.
Program growisofs seems to luckily stumble around the pitfalls.
(It has no SCSI log feature to spy on its dialog with SG_IO.)
Program cdrecord does not crash but refuses because of too much
nonsense replies.
The reports of my user indicate that the false replies do not
always happen at the same occasion.
I get the suspicion that ioctl(SG_IO) occasionally puts the SCSI
reply data into memory addresses different from those handed
over as sg_io_hdr_t.dxferp (see <scsi/sg.h>).
-------------------------------------------------------------
Conspicious incidents in the SCSI transaction log:
Already the second SCSI command sent to the drive yields an
implausible reply (line 9 of the log file):
INQUIRY
12 00 00 00 24 00
From drive: 36b
5b 00 05 32 00 00 08 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
9495 us [ 121103 ]
This means that command 12h INQUIRY was sent as the six bytes
"12 00 00 00 24 00" which are shown in hexadecimal notation.
The drive replied 36 bytes. The transaction lasted 9495
microseconds, time elapsed since libburn start is 121103
microseconds.
The reply is not plausible. According to SPC-3 specs, it
should give vendor and product name beginning at byte 8.
Some time later, the same command yields a plausible reply:
INQUIRY
12 00 00 00 24 00
From drive: 36b
05 80 05 32 5b 00 00 00 4f 70 74 69 61 72 63 20 42 44 20 52
57 20 42 44 2d 35 37 35 30 48 20 20 31 2e 30 30
470 us [ 3005485 ]
Note that not only the ASCII letters of the names appeared,
but also the device is now reported to have removable media,
and the reply is announced to have more than 4 bytes.
SPC-3, 6.4.2: "The standard INQUIRY data (see table 81)
shall contain at least 36 bytes."
We learn that the drive is an Optiarc BD-5750H Blu-ray burner.
-------------------------
In line 16 of the log file, GET CONFIGURATION is used with
minimal size in order to learn about the number of available
reply bytes.
The reply to this command is plausible and the next GET
CONFIGURATION shall fetch the list of features and profiles.
This second command replies an unplausible feature header,
a piece of a plausible profile list, and lots of zeros.
GET CONFIGURATION
46 00 00 00 00 00 00 00 08 00
From drive: 8b
00 00 01 9c 00 00 00 1b
8910 us [ 130814 ]
GET CONFIGURATION
46 00 00 00 00 00 00 01 a0 00
From drive: 416b
00 16 00 00 00 15 00 00 00 00 03 44 00 43 00 00 00 41 00 00
00 40 00 00 00 2b 00 00 00 1b 01 00 00 1a 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
... zeros to the end ...
Later in line 93 of the log file, the same gesture yields
a plausible reply:
GET CONFIGURATION
46 00 00 00 00 00 00 00 08 00
From drive: 8b
00 00 01 9c 00 00 00 1b
1020 us [ 3006688 ]
GET CONFIGURATION
46 00 00 00 00 00 00 01 a0 00
From drive: 416b
00 00 01 9c 00 00 00 1b 00 00 03 44 00 43 00 00 00 41 00 00
00 40 00 00 00 2b 00 00 00 1b 01 00 00 1a 00 00 00 16 00 00
00 15 00 00 00 14 00 00 00 13 00 00 00 12 00 00 00 11 00 00
00 10 00 00 00 0a 00 00 00 09 00 00 00 08 00 00 00 02 00 00
00 01 0b 08 00 00 00 07 01 00 00 00 00 02 07 04 02 00 00 00
... more feature bytes ...
01 0b 00 04 00 00 00 01 01 0d 08 04 1b 01 04 01
Here we learn from feature 0001h that the drive is attached
to Physical Interface standard 7 = Serial ATAPI.
-------------------------
Now comes the suspicion of wrong memory addressing:
In line 48 of the log file, immediately after the bad output
from GET CONFIGURATION, the reply is a starting piece of the
previous reply. (Needless to say that it is unplausible as
reply to a MODE SENSE for page 2Ah.)
MODE SENSE
5a 00 2a 00 00 00 00 00 1e 00
From drive: 30b
00 16 00 00 00 15 00 00 00 00 03 44 00 43 00 00 00 41 00 00
00 40 00 00 00 2b 00 00 00 1b
7452 us [ 151247 ]
Strangely, the next request for mode page 01h is fulfilled fine:
MODE SENSE
5a 00 01 00 00 00 00 00 0c 00
From drive: 12b
00 12 41 00 00 00 00 00 01 0a 80 0f
8265 us [ 160402 ]
-----------
The protest "5 24 00 INVALID FIELD IN CDB" with this
START/STOP UNIT command would be plausible if the drive tray
was not motorized. But my user reports that it does eject
sometimes. So either it can only eject and not pull in,
or we have an unplausible error indication (sense data) here:
START/STOP UNIT
1b 00 00 00 03 00
+++ sense data = 70 00 05 00 00 00 00 0A 00 00 00 00 24 00 00 C0 00 03
+++ key=5 asc=24h ascq=00h
10473 us [ 198939 ]
At least it shows no indication of mad reply.
If this is a problem, then probably an unrelated one.
-----------
Then begins a period of plausible replies, until GET CONFIGURATION
echoes the reply of a previous MODE SENSE command:
MODE SENSE
5a 00 05 00 00 00 00 00 0a 00
From drive: 10b
00 3a 41 00 00 00 00 00 05 32
499 us [ 3019491 ]
GET CONFIGURATION
46 00 00 00 00 00 00 00 08 00
From drive: 8b
00 3a 41 00 00 00 00 00
1062 us [ 3021392 ]
This lures libburn into a madly sized transaction request:
GET CONFIGURATION
46 00 00 00 00 00 00 41 04 00
cdrskin: FATAL : Failed to transfer command to drive
cdrskin: ( Most recent system error: 22 'Invalid argument' )
--- SG_IO: return= -1 , errno= 22 , host_status= 0x0 , driver_status= 0x0
(The current SVN version of libburn is supposed to detect
this situation and avoid the mad request.)
Before libburn could react on the bad outcome of ioctl(SG_IO)
there collapsed the memory management:
malloc.c:3096: sYSMALLOc: Assertion [... see above ...]
As said at the beginning of the mail, valgrind did not find
write sins in the userspace part of the program run.
There was one bad read reported (should be fixed now in SVN):
==3668== Invalid read of size 1
==3668== at 0x484C2E0: strip_spaces (drive.c:1205)
...
==3668== Address 0x4ae221f is 1 bytes before a block of size 152 alloc'd
==3668== at 0x48324E8: calloc (vg_replace_malloc.c:618)
Later valgrind's memory management collapsed:
valgrind: m_mallocfree.c:277 (mk_plain_bszB): Assertion 'bszB != 0' failed.
valgrind: This is probably caused by your program erroneously writing past the
end of a heap block and corrupting heap metadata. If you fix any
invalid writes reported by Memcheck, this assertion failure will
probably go away. Please try that before reporting this as a bug.
The bad write must have been outside the checked code.
Only the kernel comes to my mind as a suspect.
Following are the original log files on which i base my
preliminary diagnosis.
----------------------------------------------------------------------------
Full SCSI transaction log file:
----------------------------------------------------------------------------
cdrskin 1.3.6 : limited cdrecord compatibility wrapper for libburn
cdrskin: NOTE : greying out all drives besides given dev='/dev/sr0'
cdrskin: scanning for devices ...
TEST UNIT READY
00 00 00 00 00 00
9010 us [ 109778 ]
INQUIRY
12 00 00 00 24 00
From drive: 36b
5b 00 05 32 00 00 08 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
9495 us [ 121103 ]
GET CONFIGURATION
46 00 00 00 00 00 00 00 08 00
From drive: 8b
00 00 01 9c 00 00 00 1b
8910 us [ 130814 ]
GET CONFIGURATION
46 00 00 00 00 00 00 01 a0 00
From drive: 416b
00 16 00 00 00 15 00 00 00 00 03 44 00 43 00 00 00 41 00 00
00 40 00 00 00 2b 00 00 00 1b 01 00 00 1a 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
9282 us [ 142494 ]
MODE SENSE
5a 00 2a 00 00 00 00 00 1e 00
From drive: 30b
00 16 00 00 00 15 00 00 00 00 03 44 00 43 00 00 00 41 00 00
00 40 00 00 00 2b 00 00 00 1b
7452 us [ 151247 ]
MODE SENSE
5a 00 01 00 00 00 00 00 0c 00
From drive: 12b
00 12 41 00 00 00 00 00 01 0a 80 0f
8265 us [ 160402 ]
PREVENT/ALLOW MEDIA REMOVAL
1e 00 00 00 00 00
9013 us [ 169708 ]
cdrskin: ... scanning for devices done
START/STOP UNIT
1b 00 00 00 03 00
+++ sense data = 70 00 05 00 00 00 00 0A 00 00 00 00 24 00 00 C0 00 03
+++ key=5 asc=24h ascq=00h
10473 us [ 198939 ]
PREVENT/ALLOW MEDIA REMOVAL
1e 00 00 00 01 00
9640 us [ 208662 ]
START/STOP UNIT
1b 01 00 00 01 00
10091 us [ 218808 ]
TEST UNIT READY
00 00 00 00 00 00
299 us [ 719309 ]
START/STOP UNIT
1b 00 00 00 01 00
2285410 us [ 3004795 ]
INQUIRY
12 00 00 00 24 00
From drive: 36b
05 80 05 32 5b 00 00 00 4f 70 74 69 61 72 63 20 42 44 20 52
57 20 42 44 2d 35 37 35 30 48 20 20 31 2e 30 30
470 us [ 3005485 ]
GET CONFIGURATION
46 00 00 00 00 00 00 00 08 00
From drive: 8b
00 00 01 9c 00 00 00 1b
1020 us [ 3006688 ]
GET CONFIGURATION
46 00 00 00 00 00 00 01 a0 00
From drive: 416b
00 00 01 9c 00 00 00 1b 00 00 03 44 00 43 00 00 00 41 00 00
00 40 00 00 00 2b 00 00 00 1b 01 00 00 1a 00 00 00 16 00 00
00 15 00 00 00 14 00 00 00 13 00 00 00 12 00 00 00 11 00 00
00 10 00 00 00 0a 00 00 00 09 00 00 00 08 00 00 00 02 00 00
00 01 0b 08 00 00 00 07 01 00 00 00 00 02 07 04 02 00 00 00
00 03 07 04 29 00 00 00 00 04 08 04 00 00 00 00 00 10 01 08
00 00 08 00 00 10 01 00 00 1d 00 00 00 1e 08 04 83 00 00 00
00 1f 05 04 01 00 01 00 00 20 04 0c 00 00 00 00 00 00 08 00
00 10 01 00 00 21 0c 08 01 00 05 02 10 00 00 00 00 23 08 08
0b 00 00 00 00 00 00 00 00 24 04 04 80 00 00 00 00 26 00 00
00 2a 04 04 01 00 00 00 00 2b 01 04 01 00 00 00 00 2c 00 04
03 00 00 00 00 2d 08 04 46 00 3f 01 00 2e 04 04 6f 00 16 00
00 2f 08 04 4e 00 00 00 00 33 00 08 00 00 00 01 10 00 00 00
00 37 00 04 00 07 00 00 00 38 00 04 00 00 00 00 00 3b 00 04
01 00 00 00 00 40 08 1c 01 00 00 00 00 0c 00 00 00 00 00 00
00 06 00 00 00 00 00 00 00 02 00 00 00 00 00 00 00 41 04 14
00 00 00 00 00 0c 00 00 00 00 00 00 00 06 00 00 00 00 00 00
01 00 03 00 01 05 07 04 00 00 00 00 01 06 00 04 00 00 00 01
01 07 11 04 1f 00 00 00 01 08 03 0c 31 31 30 37 36 30 30 45
32 31 32 20 01 0a 01 0c 46 44 43 00 53 44 43 00 54 4f 43 00
01 0b 00 04 00 00 00 01 01 0d 08 04 1b 01 04 01
1077 us [ 3008957 ]
MODE SENSE
5a 00 2a 00 00 00 00 00 1e 00
From drive: 30b
00 3a 41 00 00 00 00 00 2a 32 3f 37 f0 77 2b 20 2b 48 00 00
11 60 2b 48 00 00 2b 48 2b 48
850 us [ 3010085 ]
MODE SENSE
5a 00 2a 00 00 00 00 00 3c 00
From drive: 60b
00 3a 41 00 00 00 00 00 2a 32 3f 37 f0 77 2b 20 2b 48 00 00
11 60 2b 48 00 00 2b 48 2b 48 00 01 00 00 00 01 2b 48 00 04
00 00 20 76 00 00 15 a4 00 00 0c fc 00 01 2b 48 00 00 00 00
847 us [ 3011240 ]
GET PERFORMANCE
ac 00 00 00 00 00 00 00 00 00 03 00
From drive: 8b
00 00 00 44 00 00 00 00
852 us [ 3012224 ]
GET PERFORMANCE
ac 00 00 00 00 00 00 00 00 04 03 00
From drive: 72b
00 00 00 44 00 00 00 00 09 00 00 00 00 23 05 3f 00 00 2b 48
00 00 2b 48 00 00 00 00 00 23 05 3f 00 00 2b 48 00 00 20 76
00 00 00 00 00 23 05 3f 00 00 15 a4 00 00 15 a4 00 00 00 00
00 23 05 3f 00 00 0d 87 00 00 0c fc
906 us [ 3013418 ]
GET PERFORMANCE
ac 00 00 00 00 00 00 00 00 04 03 00
From drive: 72b
00 00 00 44 00 00 00 00 09 00 00 00 00 23 05 3f 00 00 2b 48
00 00 2b 48 00 00 00 00 00 23 05 3f 00 00 2b 48 00 00 20 76
00 00 00 00 00 23 05 3f 00 00 15 a4 00 00 15 a4 00 00 00 00
00 23 05 3f 00 00 0d 87 00 00 0c fc
848 us [ 3014552 ]
GET PERFORMANCE
ac 10 00 00 00 00 00 00 00 00 00 00
From drive: 8b
00 00 00 14 00 00 00 00
648 us [ 3015585 ]
GET PERFORMANCE
ac 10 00 00 00 00 00 00 00 01 00 00
From drive: 24b
00 00 00 14 00 00 00 00 00 00 00 00 00 00 11 db 00 23 05 3f
00 00 2b 4b
608 us [ 3016590 ]
GET PERFORMANCE
ac 10 00 00 00 00 00 00 00 01 00 00
From drive: 24b
00 00 00 14 00 00 00 00 00 00 00 00 00 00 11 db 00 23 05 3f
00 00 2b 4b
608 us [ 3017728 ]
MODE SENSE
5a 00 01 00 00 00 00 00 0c 00
From drive: 12b
00 12 41 00 00 00 00 00 01 0a 80 0f
459 us [ 3018605 ]
MODE SENSE
5a 00 05 00 00 00 00 00 0a 00
From drive: 10b
00 3a 41 00 00 00 00 00 05 32
499 us [ 3019491 ]
GET CONFIGURATION
46 00 00 00 00 00 00 00 08 00
From drive: 8b
00 3a 41 00 00 00 00 00
1062 us [ 3021392 ]
GET CONFIGURATION
46 00 00 00 00 00 00 41 04 00
cdrskin: FATAL : Failed to transfer command to drive
cdrskin: ( Most recent system error: 22 'Invalid argument' )
--- SG_IO: return= -1 , errno= 22 , host_status= 0x0 , driver_status= 0x0
cdrskin: malloc.c:3096: sYSMALLOc: Assertion `(old_top == (((mbinptr) (((char *) &((av)->bins[((1) - 1) * 2])) - __builtin_offsetof (struct malloc_chunk, fd)))) && old_size == 0) || ((unsigned long) (old_size) >= (unsigned long)((((__builtin_offsetof (struct malloc_chunk, fd_nextsize))+((2 * (sizeof(size_t))) - 1)) & ~((2 * (sizeof(size_t))) - 1))) && ((old_top)->size & 0x1) && ((unsigned long)old_end & pagemask) == 0)' failed.
UNIX-SIGNAL: SIGABRT errno= 22
cdrskin: ABORT : Handling started. Please do not press CTRL+C now.
cdrskin: ABORT : Trying to ignore any further signals
cdrskin: ABORT : Abort processing depends on speed and buffer size
cdrskin: ABORT : Usually it is done with 4x speed after about a MINUTE
cdrskin: URGE : But wait at least the normal burning time before any kill -9
cdrskin: ABORT : Urged drive worker threads to do emergency halt.
----------------------------------------------------------------------------
Full valgrind log of a similar run:
----------------------------------------------------------------------------
==3668== Memcheck, a memory error detector
==3668== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==3668== Using Valgrind-3.9.0 and LibVEX; rerun with -h for copyright info
==3668== Command: cdrskin dev=/dev/sr0 -msinfo
==3668==
cdrskin 1.3.6 : limited cdrecord compatibility wrapper for libburn
cdrskin: NOTE : greying out all drives besides given dev='/dev/sr0'
cdrskin: scanning for devices ...
==3668== Thread 2:
==3668== Invalid read of size 1
==3668== at 0x484C2E0: strip_spaces (drive.c:1205)
==3668== by 0x48517EB: burn_drive_scan_sync (drive.c:1239)
==3668== by 0x48478A7: scan_worker_func (async.c:230)
==3668== by 0x4912B0F: start_thread (in /lib/libpthread-2.13.so)
==3668== Address 0x4ae221f is 1 bytes before a block of size 152 alloc'd
==3668== at 0x48324E8: calloc (vg_replace_malloc.c:618)
==3668== by 0x48514FB: burn_drive_scan_sync (drive.c:1413)
==3668== by 0x48478A7: scan_worker_func (async.c:230)
==3668== by 0x4912B0F: start_thread (in /lib/libpthread-2.13.so)
==3668==
cdrskin: ... scanning for devices done
cdrskin: FATAL : Failed to transfer command to drive
cdrskin: ( Most recent system error: 22 'Invalid argument' )
valgrind: m_mallocfree.c:277 (mk_plain_bszB): Assertion 'bszB != 0' failed.
valgrind: This is probably caused by your program erroneously writing past the
end of a heap block and corrupting heap metadata. If you fix any
invalid writes reported by Memcheck, this assertion failure will
probably go away. Please try that before reporting this as a bug.
==3668== at 0x3804C24C: ??? (in /usr/local/lib/valgrind/memcheck-arm-linux)
sched status:
running_tid=1
Thread 1: status = VgTs_Runnable
==3668== at 0x48324E8: calloc (vg_replace_malloc.c:618)
==3668== by 0x4854843: burn_alloc_mem (init.c:657)
==3668== by 0x4861C27: sg_close_drive_fd (sg-linux.c:608)
==3668== by 0x486273B: react_on_drive_loss.isra.5 (sg-linux.c:2040)
==3668== by 0x4863097: sg_issue_command (sg-linux.c:2187)
==3668== by 0x485B67F: mmc_get_configuration_al (mmc.c:2972)
==3668== by 0x485CA17: mmc_get_configuration (mmc.c:3250)
==3668== by 0x485D47F: mmc_read_disc_info (mmc.c:1912)
==3668== by 0x4865DAB: spc_sense_write_params (spc.c:797)
==3668== by 0x484C63B: burn_drive_inquire_media (drive.c:273)
==3668== by 0x48503B3: burn_drive_grab (drive.c:536)
==3668== by 0x12E13: Cdrskin_grab_drive (cdrskin.c:4132)
==3668== by 0x1B71F: Cdrskin_msinfo (cdrskin.c:7873)
==3668== by 0x20217: Cdrskin_run (cdrskin.c:9515)
==3668== by 0xB5F3: main (cdrskin.c:9691)Best Regards
------------------
Note: see also the FAQ in the source distribution.
It contains workarounds to several common problems.
In particular, if Valgrind aborted or crashed after
identifying problems in your program, there's a good chance
that fixing those problems will prevent Valgrind aborting or
crashing, especially if it happened in m_mallocfree.c.
If that doesn't help, please report this bug to: www.valgrind.org
In the bug report, send all the above text, the valgrind
version, and what OS and version you are using. Thanks.
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Best Regards
------------------
Lian jianfei
5F, No.15, Ke Hui 2nd Street, Ke Hui Development Centre Science Avenue, Science City, Luo Gang District Guangzhou, China 510663
TEL: 15989094327
Email: lianjf at ava.com.cn
From: Wally Yeh
Date: 2014-08-19 16:23
To: lianjf at ava.com.cn
CC: meta-freescale
Subject: Re: [meta-freescale] about freescale dvd-rom
Hi, Lian:
how do you test? so you just plug the usb external dvd drive , then you wish there are some application will pop up and play the content in the DVD?
Wally
2014-08-19 15:33 GMT+08:00 lianjf at ava.com.cn <lianjf at ava.com.cn>:
Hi ,
Can anyone tell me freescale imx6q arm board support dvd-rom perfectly?I test it ,but it seems that it doesnot work okay.
Any help would be appreciated.
Best Regards
------------------
Lian jianfei
5F, No.15, Ke Hui 2nd Street, Ke Hui Development Centre Science Avenue, Science City, Luo Gang District Guangzhou, China 510663
TEL: 15989094327
Email: lianjf at ava.com.cn
--
_______________________________________________
meta-freescale mailing list
meta-freescale at yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-freescale
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/meta-freescale/attachments/20140819/614ced5f/attachment-0001.html>
More information about the meta-freescale
mailing list