Meizu M6 "miniplayer"

[gevaerts]

I got 0x0154 out of my m6sl a while ago. Since then a lot of clock-related things have changed though, so timings are probably totally wrong

[jensu]

yes, i've seen this and tried to fix it. but i'm not used to read such datasheets.
thanks for the info gevaerts, i'll keep on trying to get the id too

[zorgblaubaer]

how do i get out data like that out of my m6sl anyway? i am clueless... ;(

i only worked with atmel chipsets untill now and those are documented, which isnt true for the meizu (for obvious reasons).. but i would really like to contribute.. maybe someone of you can give me some hints where to go for learning stuff like that

[AlexP]

I've just removed a few asking for updates posts.  Please people, do not post asking for updates.  If and when there is anything to say, it will be posted here.

[paul356]

Hey, guys. I own a M6SL. The official firmware from Meizu company sometimes is annoying. So I fully support porting rockbox onto Meizu players. Though I don't know much about arm, I have some C/C++ programming experience. If you need any help, please let me know.

EDIT: I can't get the through the dfu process. I am always got stuck at the get_cpu operation after "Wait a sec (literally)..." . Anybody can give me a hint?

[saab_rider]

saab_rider:

A bit of a cheeky request - any chance you/your friend could PM the original poster and explain that Rockbox is written by volunteers in their spare time, and it would need a chinese speaking volunteer to invest a very large amount of time to keep a translation up to date.

Just wanted to let other Meizu M6 users know...  I as BigBambi suggested a while back and contacted the Chinese guy who posted in this thread in Chinese (my translation is right below it).

This is his response:

謝謝你！
我是個學生，我倒是知道中文，但是我英文一般
我挺了解中國mp3市場的，我也有N多mp3
雖然在語言方面我沒有辦法幫RB
但是如果叫我找mp3或是查某mp3的資料
我會盡力幫忙的！

Translation:
Thank you!
I'm a student, and my English is weak.
I'm very familiar with China's MP3 market (I assume he means DAP market), and I have many MP3s (again I assume he means MP3 players).
Although I can't help RB due to the language barrier, however if anyone needs me to find a specific MP3 player or even a specific MP3 player's specs. I'll try my best to help!


So there you have it You can either contact the guy directly, or send me instead...
Thank

[yijie]

EDIT: I can't get the through the dfu process. I am always got stuck at the get_cpu operation after "Wait a sec (literally)..." . Anybody can give me a hint?

I also got stuck here, can anyone help?
Here is what i got using command: meizu_dfu m6sl rockboot.ebn rockboot.ebn

Reading rockboot.ebn...OK
Reading rockboot.ebn...OK
USB initialization... Device found.
GET CPU, got: S5L8700 Rev.2
GET CPU, got: S5L8700 Rev.2
Sending rockboot.ebn... ####### OK
Wait a sec (literally)... OK
Releasing interface... OK
USB initialization... Device found.
GET CPU
Error trying to get CPU model, exiting.

[wpyh]

To those who got stuck at the DFU process: You have to hold down the M and Play buttons during the whole process. Please try again and see if it works now.

[paul356]

To those who can successfully run the DFU process on the M6SL:
          I have been stuck in the DFU process for a long time and have the same problem as yijie. Could any explain the DFU process on the M6SL more precisely? So we can find where the problem is. There are some people like me who are willing to help this project but can't run test code on M6SL because of the DFU problem. If we can run code on our player, I think more people can really help this project.

[l4]

As there is few posts here about getting stuck at the GET CPU I have decided to dig into this.
During this process there is the part where you need to hold the buttons. To know you are holding them right (as wpyh suggests we are not , you can see in the lsusb --verbose (a linux command) the device is seen as 2 Blues USB DFU Device and also the DFU tool does not show the No device found.

If you look into the meizu_dfu source you'll notice there are duplicate lines of get_cpu(device) which was suspicious to me. Markun said he commented one of them out and the dfu tool works on his FreeBSD. I don't know if before modification it did not work for him but it did not solve my get_cpu() problem. I am not an experienced programmer but I will try to find out whats going wrong.

Guys who know their C and the sauce around, don't whine about not being to help cause of little difficulty and take a closer look at the get_cpu()  function of the dfu tool. I will try and will update this post in case I find some usefull hints or even solve the problem. (I own the M6SL version, please state your miniplayer version just in case )

[gevaerts]

OK, there seems to be a lot of confusion about the meizu_dfu tool, so maybe I should mention some facts:

get_cpu() is executed twice to match the behaviour of the original windows dfu tool that's mentioned on the meizume forums.

meizu_dfu is designed to upload a firmware file, wait for it to start running and start its own dfu mode, and upload another file. This is because that's what you need to do to install the OF.
For running the rockbox test code, you only need one, and it doesn't speak dfu itself, so the second set of get_cpu() and upload fails.
Of course, some changes to the meizu_dfu code to have a mode where it only tries upload a single file (maybe by looking at how many files it's given on the command line) would be welcome

[l4]

I am glad gevaerts pointed out these facts. I have debugged and resolved my get_cpu issue which opposed to yijie's was in failing to get_cpu even before the first image was sent. Now what is happening is after sending the first image, the USB connection is reset to be reestablished with the upload code that has been sent in the first image. I got 'No Device Found' on the atempt to reestablish the connection. This is due to the player not being rediscovered during the 'Wait a sec (literally)..." message. This can be avoided by changing the waiting interval to 2 seconds.
If you encounter this issue just go to the rockbox/utils/meizu_df/meizu_dfu.c and change the sleep(1) to sleep(2) (in the code that is used for your version of player!). Now recompile the dfu tool and try again.
My status is now hanging on sending the second image. I assume the update code is not accepting it (most likely my fault) but I know its running as it is returning the CPU model S5L8700 Rev.2-BE  070831
(If anyone has a feeling that random thoughts of two minds is better than just one, visit the IRC, you can catch me with /msg l403 on freenode)

[yijie]

Thanks everyone! Finally I get response.

To wpyh: I tried to hold two buttons down all the time, but failed again.  And if I press only M button, the command meizu_dfu updateNAND_BE_070831.dfu M6SL.ebn works.

Seems like after the first image updateNAND_BE_070831.dfu was uploaded, it begins to run. So, what is the address does it run from? Can we make rockboot.ebn run on this address and discard the second satge?

[gevaerts]

Seems like after the first image updateNAND_BE_070831.dfu was uploaded, it begins to run. So, what is the address does it run from? Can we make rockboot.ebn run on this address and discard the second satge?

We can, and that's why we do that.

[bertrik]

Hi all,
gevaerts lent me his Meizu M3 and I'm working on getting more stuff to work on it. So far we've been able to control the backlight brightness by doing interrupt-driven PWM, getting the i2c bus to work so we can talk to the codec and the real-time-clock chip. Hopefully we'll soon be able to communicate with the radio chip too.