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 [email protected]. ----------------------------------------------------------------------------------------------------------------------------------------------------- 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: [email protected] From: Wally Yeh Date: 2014-08-19 16:23 To: [email protected] 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 [email protected] <[email protected]>: 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: [email protected] -- _______________________________________________ meta-freescale mailing list [email protected] https://lists.yoctoproject.org/listinfo/meta-freescale
-- _______________________________________________ meta-freescale mailing list [email protected] https://lists.yoctoproject.org/listinfo/meta-freescale
