the bug about dvd driver attached via SATA on freescale i.MX_6_SABRE-SD arm board

lianjianfei · ‎08-28-2014

I have found a bug about dvd driver attached via SATA on freescale i.MX_6_SABRE-SD arm board.It cannot support to burn the dvd-rom normally.

I have made some experiments on i386 and another kind of arm board with the same burning tool,they turn to be okay.To confirm it is the problem of imx6,i have tried another burning software,but it turns the same case.

So I turn to the developer of the burning software,he suspects there must be something wrong with "Linux BSP" provided by Freescale.

I would be grateful if you can help to submit this bug to freescale.

What is more,the developer of the burning software Thomas Schmitt would be insterested in this bug and be willing to help to test it ,his mail is :scdbackup@gmx.net.

And here is his analysis:

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

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

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== 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.

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

HeikkiJuntunen · ‎03-12-2015

Hello,

Any news? I'm *very* interested in this issue.

CarlosCasillas · ‎09-23-2014

Hi lian,

Could you please specify what's the source codes baseline(kernel version?) you used?

As an additional test/detail: Have you tested this DVD burner on a regular PC running Linux? Does it work properly?

Best regards!

/Carlos.

lianjianfei · ‎09-24-2014

>Could you please specify what's the source codes baseline(kernel version?) you used?

The kernel version i have used are linux-3.0.35 and linux-imx-3.10.17,they dont work.

>Have you tested this DVD burner on a regular PC running Linux? Does it work properly?

As i have said, I have made some experiments on i386 and another kind of arm board with the same burning tool,they turn to be okay.So this DVD burner on a regular PC running Linux work properly.So the hardware or the bsp of freescale arm board is to be blamed.

CarlosCasillas · ‎10-14-2014

Hi,

AE team is still working on it, we will send you an update as soon as having some news.

Best regards!

/Carlos.

lianjianfei · ‎02-01-2015

Such a long time have not receive any message from you,does the problem has any solution ?

CarlosCasillas · ‎02-03-2015

Hi lian,

Sorry for the delayed reply. In order to perform additional tests, could you please you share the DVD burner program used at your side?

With your dedicated program and usage how-to, it would be easier for us to setup the test environment at our side.

We will be waiting for your reply.

Best regards!

/Carlos

lianjianfei · ‎02-05-2015

you can download the program from the websize:http://scdbackup.sourceforge.net/xorriso-1.3.9.tar.gz

after building it ,you can use run the command:xorriso -help to show the usage how-to,as for the buring file,you can run:

> xorriso -md5 on -dev /dev/sr0 \

> -joliet on -local_charset UTF-8 -charset UTF-8 \

> -map test_dir /test_dir

/dev/sr0 is the dvdrom device note,test_dir /test_dir are the file you want to add to the disk and the system path.

CarlosCasillas · ‎04-10-2015

Hi lian,

Do you still having troubles regarding this case? AE team is still waiting for the additional details.

Best regards!

/Carlos

CarlosCasillas · ‎04-07-2015

Hi,

AE team has commented the following:

Do you know to do the CROSS_COMPILE and make the target system as ARM when build the burner program (/xorriso)?

I can't find the related information in the README file and so on.

Do you have additional details regarding this?

Best regards!

/Carlos

fabio_estevam · ‎09-19-2014

Which kernel version do you use? Can you try 3.16.2 or 3.17-rc5?

lianjianfei · ‎09-24-2014

Hi,i am so glad somebody shows interests in it.The kernel version i have used are linux-3.0.35 and linux-imx-3.10.17,they dont work.

>Can you try 3.16.2 or 3.17-rc5?

where i can down 3.16.2 or 3.17-rc5? My freescale arm board is i.MX_6_SABRE-SD.

CarlosCasillas · ‎09-19-2014

Hi,

We are internally reviewing your request because it seems that nobody else have used a DVD-ROM on Freescale BSP.

If you have additional detail and/or updates, please post them here.

Best regards!

/Carlos