On Thu, 8 May 2014 00:07:29 +0200 Idwer Vollering vidwer@gmail.com wrote:
Adding the lead developers to CC.
And the mailing list... this should be public IMHO.
2014-05-07 23:59 GMT+02:00 Alexandre Boeglin alex@boeglin.org:
Le mardi 06 mai 2014 à 16:09, Alexandre Boeglin a écrit:
Le mardi 06 mai 2014 à 15:11, Idwer Vollering a écrit:
However, using my Dell screen, every file written/read with -p mstarddc_spi will have the first byte rotated, so verify will always fail:
I have other screens available, I'll check if they use MSTAR SoCs…
Well, I tried with a BenQ FP93GX I had, which also seem to have the same ISP port.
I tried to probe it, but with no luck.
After closer inspection, it seems that I have the same rotation issue, even in the RES command, which makes it impossible to identify the flash chip:
Probing for PMC Pm25LV010, 128 kB: programmer_map_flash_region: mapping flash chip from 0x00000000fffe0000 to 0x0000000000000000 RES returned 0x9d 0x7c 0x7f. probe_spi_res3: id1 0x9d7c, id2 0x7f
It returns "0x9d 0x7c 0x7f", whereas I think it should return "0x7f 0x9d 0x7c"…
But then, without documentation from MSTAR, I don't really know how to differentiate between screens that have the bug, and those that don't.
We could add a programmer parameter and let the user decide/override until we understand this better. Does the DDC tunnel still work with a broken firmware or is an external programmer needed if the first try to modify the firmware fails and the SoC inside the device is reset?