Rockbox Technical Forums
Rockbox Development => New Ports => Topic started by: ii on March 04, 2014, 05:01:31 PM
-
The old topic is closed, so have to start this new one, with some new details.
iBasso DX50 is android-based, but is not nearly capable of running the android port of rockbox.
This because the original firmware has nothing for java code support; instead, the player software is fully written in C/C++ with android ndk.
It's easy to modify the firmware contents; enable adb; run custom code and access internal devices.
Current status:
- almost done
- sound (including spdif), screen, touchscreen, buttons, headphones detection, filesystem, battery readout, volume control, backlight control, poweroff/reboot working
- dual boot scheme working, with swapping both player and vold
TODO:
- install process for users
- capture power button longpress for turnoff (how?)
- settings save
- screen turnoff
- better keymap, e.g. in equalizer
- hires audio (?)
- prepare code branch for merging back into master
Sources + downloads: https://bitbucket.org/isergachev/rockbox/wiki/Home
Possible developers / advanced users are welcome.
-
-
-
I can't wrap my head around this - android without dalvik. That would be pure linux then.
-
I can't wrap my head around this - android without dalvik. That would be pure linux then.
Perhaps they took a SOC that had Android support and simply targeted the Linux parts rather than Dalvik? Certainly a strange result, but I guess nowadays android is replacing traditional embedded linux so maybe thats all the SOC came with.
Edit: Renamed title since we certainly won't be deleting this thread.
-
saratoga,
mb not enough ram ? DX50 based on Rockchip RK2926, DX100 - RK2918.
RK2926/RK2928 is updated from RK2918, and they are changed in the old architecture of previous generation products, using the new Cortex-A9 architecture
btw, for hi-end HiFiMan HM901(Ingenic JZ4760B) used Android too. for mips! freaky! FiiO X5\X3 based on JZ4760 used µC/OS-II.
-
saratoga,
mb not enough ram ? DX50 based on Rockchip RK2926, DX100 - RK2918.
RK2926/RK2928 is updated from RK2918, and they are changed in the old architecture of previous generation products, using the new Cortex-A9 architecture
btw, for hi-end HiFiMan HM901(Ingenic JZ4760B) used Android too. for mips! freaky! FiiO X5\X3 based on JZ4760 used µC/OS-II.
root@android:/ # cat /proc/meminfo
MemTotal: 408348 kB
MemFree: 375400 kB
-
#sage
I have been stuck at activating adb, i played with every damn parameters of the configs file to get no results. Will your git include the whole image or just the RB sources?
-
Right now I'm only working on rockbox inself.
Of course we will need to develop some kind of installer later.
Enabling adb is as easy as
setprop persist.sys.usb.config adb
setprop persist.usb.debug 1
; see /bin/openadb in stock firmware.
You can get an adb-enabled image of 1.2.8 at https://mega.co.nz/#!Ih5QTJzI!0DXEqNgJBWeK1QFqTeOhXW5KaH6LP4Vi0M38Wtd2PZM
-
I looked at your repo and this port looks much more like other hosted linux ports then android. Anyway nice to see progress. I strongly recommend to pop-up on IRC.
-
I looked at your repo and this port looks much more like other hosted linux ports then android. Anyway nice to see progress. I strongly recommend to pop-up on IRC.
Sure! It's a linux. But android config of rockbox uses ndk, that's why I've chosen it.
Someone will have to explain me later what is the proper way for integrating this port into the build system.
Ok, going to IRC.
-
Right now I'm only working on rockbox inself.
Of course we will need to develop some kind of installer later.
Enabling adb is as easy as
setprop persist.sys.usb.config adb
setprop persist.usb.debug 1
; see /bin/openadb in stock firmware.
You can get an adb-enabled image of 1.2.8 at https://mega.co.nz/#!Ih5QTJzI!0DXEqNgJBWeK1QFqTeOhXW5KaH6LP4Vi0M38Wtd2PZM
Duh. Thanks for both.
I love the trick to boot on rockbox with the ln -s :D
I'll try to lend you a hand, even though im not a RB core dev :)
Edit : let's start with ? : http://www.rockbox.org/wiki/PortingHowTo
Edit2 : by installing directly through adb, the backup system will reinstall the backup image booting on mangoplayer, right?
-
I love the trick to boot on rockbox with the ln -s :D
I'll try to lend you a hand, even though im not a RB core dev :)
Edit : let's start with ? : http://www.rockbox.org/wiki/PortingHowTo
Edit2 : by installing directly through adb, the backup system will reinstall the backup image booting on mangoplayer, right?
Actually I've done a simple launcher, which captures keypresses, manages symlinks and allows switching players.
The launcher replaces MangoPlayer at /system/bin. I'll share its source.
Do you mean that you want to write proper config for building for dx50 separately from android? That would be great!
-
Actually I've done a simple launcher, which captures keypresses, manages symlinks and allows switching players.
The launcher replaces MangoPlayer at /system/bin. I'll share its source.
So you actually can "double boot" somehow, nice !
Do you mean that you want to write proper config for building for dx50 separately from android? That would be great!
I dont really get your point. If i am right, you're actually using the android RB port, however going through the "original" port of RB would require cross compiling. It's doable, but it's a choice to make at the beginning of the project, since both ports are quite different to my knowledge.
-
So you actually can "double boot" somehow, nice !
I dont really get your point. If i am right, you're actually using the android RB port, however going through the "original" port of RB would require cross compiling. It's doable, but it's a choice to make at the beginning of the project, since both ports are quite different to my knowledge.
Yes, dualboot.
I mean, soon or late we have to split from android port and create another config entry in tools/configure + separate folders, sources etc.
Android port does not need the modifications I've made to it :)
-
I saw a comment about the SOC not having a real time clock that persisted between runs. That is very strange. Which SOC is the DX50 using?
-
RK2928.
simple check: you start it up and run 'date' in adb shell
it runs from epoch after each power-on
-
I have iBasso DX50 running ROCKbox very well. I am wondering if port for iBasso DX50 will become official port listed and sownloadable from this portal?
-
If/when the developer splits it out from the current RaaA for Android build and it becomes its own target in our configure/build system, and assuming the code meets style and licensing guidelines - then, you will see it hit the front page.
Until then, patience.
[Saint]
-
If/when the developer splits it out from the current RaaA for Android build and it becomes its own target in our configure/build system, and assuming the code meets style and licensing guidelines - then, you will see it hit the front page.
Until then, patience.
[Saint]
Thank you.
-
I'm using this version of rockbox on my DX50, and it works great, mostly!
The Random Folder Advance Configuration plugin isn't working - it just counts up to some crazy high number endlessly until stopped manually. I'm hoping this can get fixed fairly soon, as this is an important feature for me. Unless there's a workaround way to get it working? Manually creating a folder list or something?
-
I don't use the plugin myself, but have you tried limiting the search to the directories with your audio in with /.rockbox/folder_advance_dir.txt?
http://download.rockbox.org/daily/manual/rockbox-sansaclipzip/rockbox-buildch12.html#x15-30000012.4.14
-
Thanks, I'll give it a shot. Tomorrow maybe.
Edit - it works! Thanks for the pointer. Note to others wanting to use this fix - just a simple .txt file named folder_advance_dir.txt containing these lines:
/mnt/external_sd/
/sdcard/
(assuming you have a micro sd card, if not omit the first line) - place this in your .rockbox directory, you're done! Run the random folder advance config plugin. When editing the list you can delete items by swiping to the left - it's kind of hit and miss until you figure it out, but it works.
-
I really hope that "Il" will find the time to adapt his source to make it compatible to the the official build mechanism and to finally introduce it as an official build.
I'm pretty much done with the graphic for the DX50. So at least there will be one little thing less to do:
(http://abload.de/img/dx50_xgjvf.png)
-
Its slightly unfortunate that this port came to life in the way it did, but hardly the end of the world.
If I were to speculate I would say that ii created this initially for his/her sole usage, so modifying an existing target was seen to be the best course of action. Its not really a huge issue, it just makes it slightly inconvenient at this stage when it comes time to sever the two.
[Saint]
-
Hello everyone.
As everybody here knows, Il made a working port which is available at
https://bitbucket.org/isergachev/rockbox/wiki/Home
I can't say enough times "thank you!" for that Il!
And: some more good news: headwhacker@head-fi (and a bit me) made the necessary changes to make it work on DX90 which is a very similar device.
But what Il did is modifying the "android" target instead of making a new target (what of course makes it much easier to start).
His intention was to make the target an official port one day, but I think that he is very busy and that day will be very far from today ;)
So even if i'm not a experienced programmer (specially 0% knowledge of android) I look at it as my destiny to make this port rockbox compliant, because otherwise it will always be dependent on Il. Maybe I will need a little help and hope that some experienced rockboxers will help me a little bit.
So one of my questions is: Am I doing the right things now. Because the work is not much fun, I only want to do it if it is worth it.
Ok, what I did was a checkout of Il's code and the official rb code at the same revision and did a recursive diff. Then I started with the tools/configure and added the 2 Targets. My goal is to make it possible that android targets compiles as before and that there will be DX90 and DX50 that compile like with Il's sources.
More questions:
- Can I reserve numbers for targets (in tools/configure)
- Il used tinyalsa and included .c files of the tinyalsa project in his code. Will they be allowed or do they have to be taken from the compiler libriary (as original android port does?)
I will have much more problems, but this are my first ones....
-
"Reserve numbers" in what way?
I think tinyalsa is clearly acceptable if it makes the port easier/more stable.
-
the number of the target.
But nevermind, updating the configure script will be the smallest thing compared to the whole new port.
And about tinyalsa, I'm not sure but maybe he only included it because alsa libs are not included in the SDK by default.
-
Hello everyone. Just a status update:
I've finished to put all changes that Il did into separate files or comment out by ifdef for the 2 new targets DX50 and DX90 and I successfully compiled rockbox for DX50 :) :).
What I will do next are some code cleanups. I will also have to make new definitions that are unique for this port until now but could be helpful for new ports in the future in /rockbox/firmware/export/config/ibassodx50.h and ...dx90.h (something like "tinyalsa", "use_jni" and "android-standalone")
-
Once its compiling cleanly, you should post your changes to gerrit so that other people can review them and provide feedback. Its usually best to get that early rather than later.
-
Thanks!
I will do that after some cleanup. I will also have to try out if the target "android" is still compiling as it should.
-
Hello. My status in this project is that i'm quite far but I still would like to optimize some things first before doing a commit.
But why i'm writing is that i need some help from a developer. Ilias port has always had the problem that as soon as playback starts, all timer acitities are slowed down by a factor around 2.3 (backlight timeout, scrolling acceleration, stopwatch, etc.) . When playback stops or is on pause, everything is normal again. can it be that a timer tick takes too long time and lets some other timer slow down? To be more specific: that the pcm_tick takes too long? I dont know much about timers and maybe I could find it out myself, but a small tip from a experienced dev. could save me hours of investigation :) .
Edit: no more help needed, foud how to solve the problem partly.
-
As was pointed out earlier you should really, really put your work-in-progress on gerrit. That way others can review the code on early stage saving you hassle later.
-
Uploaded the code to gerrit:
http://gerrit.rockbox.org/r/#/c/941/
-
The link to the bitbucket repo seems to be down. :(
-
Never mind, it's just the period at the end of the URL... :-[
-
Good news: headwhacker announced to have solved the "gather runtime data" - bug for this port. :)
-
I committed the port. However, its not integrated into our build system. From what I understand, we don't current build Android targets over the build system. Is there a technical reason why we could not build the DX50/90 devices this way?
Also, I've created a wiki page:
http://www.rockbox.org/wiki/IBassoDXPort
Filling this out with install directions and any other useful info would be great.
-
Thanks a lot for everything!
I don't know why android apps are not build, didn't do the reading for it. But it is not impossible that the reason could also affect DX50/90 port.?
At current state, no simple installation is possible. But I will try to get further with this. Also writing the wiki and fixing the DX90 port (maybe headwhacker helps me, now that it is so easy to get the sources) are my homework. I only have limited time (some hours a week) but I will bring this port to the end if my abilities allow it
-
I had a spontaneous idea for the update mechanism:
The app and libs could be installed to the data partition. The dualboot-app (/rbutil/ibassoboot) could be extended to manage updates, so if there is a rockbox.zip on the sdcard it updates the rockbox app on the data partition. So the official firmware would only need to be patched once with the dualboot-app.
-
I committed the port. However, its not integrated into our build system. From what I understand, we don't current build Android targets over the build system.
So, I screwed up.
If anyone read the comment I posted prior where I confirmed and agreed with this, I apologise.
It seems Android targets are indeed hitting the build table, and that Chrome decided to hate me and not show them (and may other) items in the build table. Serves me right for religiously using Chrome-dev I guess.
[Saint]
-
a very small breakthrough for the installation process: Because my mate headwhacker form head-fi insisited in trying to install the whole rockbox to /sdcard (internal drive) we tried to find a way and found it. With this way it will be possible to do updates of rockbox using only mass storage, nothing else :D . I will do some more testing and post a patch when I'm 100% sure it works.
-
The DX50 is now actually built by our build system:
http://build.rockbox.org/dev.cgi
The first build went smoothly:
http://build.rockbox.org/shownewlog.cgi?rev=be9c227;type=ibassodx50
-
Wow, that's great! :D
We are getting further and further. Thanks!
I have a question about folder structure. Until now we had the content of the rockbox.zip on the system partition. Also the libs/armeabi/* was on the system partition in an other folder. The user setting were on /sdcard/rockbox. Now if we move the binaries to sdcard, how sould it be done?
a)
everything (settings AND build) to
/sdcard/rockbox
libs/armeabi to
/sdcard/rockbox/bin
b)
build to
/sdcard/.rockbox
settings remain in
/sdcard/rockbox
libs/armeabi to
/sdcard/.rockbox/libs/armeabi
or even something else?
On my known players (H120 and clip+) it is the way a) but with a dot (.rockbox)
Edit: I think I have a basic lack of knowledge about the android port. Right now we are running the rockbox binary in the folder with all the lib*.so 's from libs/armeabi. But is this necesary? All files are already in the zip. Is it possible to run it without the lib*.so's?
Edit2: My gerrit patch uses finally this folder structure:
everything (settings AND build) to
/sdcard/.rockbox
libs/armeabi to
/sdcard/.rockbox/codecs
-
Next step:
DX50 (& hopefully DX90) run well from sdcard:
http://gerrit.rockbox.org/r/#/c/993/ (http://gerrit.rockbox.org/r/#/c/993/)
This will simplify the update procedure of rockbox by a big amount.
to try the installation (tested on DX50) when coming from ilia's build:
- build the dualboot selector in rbutils/ibassoboot with ndk-build and copy the build (MangoPlayer) to /system/bin/
- copy rbutils/ibassoboot/chooser.bmp and rbmissing.bmp to /system/
- build rockbox: make zip
- copy the content of the rockbox.zip to the internal drive /mnt/sdcard
The new file structure differs only by the codecs filenames from a regular build :).
Edit: Had to change the gerrit address because I made accidentally a new commit instead of a new patch set
Edit2: with modified buildzip.pl even 1 step less is needed :-)
-
I'm currently tinkering around with this build. It builds and it works. Moving the rockbox directory to the sdcard is great.
The only thing i do not like is the current keymap. Specifically hold switch and power button interaction with the touchscreen/backlight.
As it is right now
- every press of a physical button turns on the touchscreen.
- the hold switch locks the touchscreen and the physical buttons.
Which is really annoying if you try to use the device blindly (e.g. while it is in your pocket).
In my personal build i reverted the behaviour somewhat back to the original implementation by isergachev:
- Hold switch only toggles touchscreen lock/backlight.
- Hold switch only locks power button short press (to prevent accidentally leaving WPS).
I tried doing this with the rockbox infrastructure, but failed miserably (to much unfamiliar code and concepts in to short a time). So i hacked up the iBasso key code.
IMHO the power button/lock switch behaviour should be this (for this device):
- Hold switch only toggles touchscreen lock/backlight.
- Power button short press only toggles backlight.
- While hold switch is set to lock, no button press or automatic interaction (e.g. caption backlight) turns on the touchscreen/backlight.
- Current function of the power button (back/abort) can be fully replaced with touchscreen interaction.
Any comments?
Can this be achieved "The Rockbox Way"?
Can this be made the default behaviour? Or at least be customizable?
Or will i ever need a custom build for this?
-
In my builds at head-fi I've included a mod that I called "Spartphone UI style". I had to take this out to get the port commited. To be honest, this mod has a very low possibility to get ever accepted :( (even if I did it in a very clean way). But anyway I will do a commit to gerrit that you can cherry-pick it.
This mod changes:
- in main menu -> power brings you to resume
- in wps -> power toggles backlight, other buttons don't turn on backlight
The concept of this mod is that WPS should be the main screen, not the main menu (exept when playback is stopped).
This concept is today more intuitive than in 2002 because we got brainwashed by using Mobil Phones (iPhone and Android) in the past ~5 Years.
-
Here is the promised patch:
http://gerrit.rockbox.org/r/#/c/1007/ (http://gerrit.rockbox.org/r/#/c/1007/)
-
Here is the promised patch:
http://gerrit.rockbox.org/r/#/c/1007/ (http://gerrit.rockbox.org/r/#/c/1007/)
Thx. Works.
Well it did, after i spend several hours trying to figure out why this &"§%§ build would skip every &$§& track. Turns out, that Rockbox will do this if it can not load the codecs, which where named .so instead of the default.
Maybe i shouldn't play git at 1am in the morning ...
-
Hello everyone,
I'm not sure if this is the right thread as I am not an expert whatsoever, but before I open a new topic about the iBasso DX50, I figured I should try my luck here.
I have been using Rockbox for quite a while now, I had it installed on an iRiver H340, a Cowon X5, Sansa Clip Plus and even on the iPod Classic (which is not one of the "officially" supported devices).
Lately, I got myself an iBasso DX50 - and the main reason to buy it was indeed the Rockbox port which is already out there.
However, I have to admit that I didn't get it to work properly. I'm sorry that I cannot describe everything in detail because of my lack in technical knowledge, but maybe you can still help me.
In order to install, I followed the instructions given on several webpages. I used the cholero version and the RKbatch tool to flash.
It was quite fiddly for me, but in the end I got RB working. 2 problems came up though:
1) I didn't get any sound. At first there was a crackling in my headphones, but then nothing. HOWEVER, this might be a result of my own stupidity. I am not sure if I didn't accidentally plug my headphones into the COAX out of the DX50. I am still not used to the headphone outs sitting on the BOTTOM of the player. I read that others had a similar issue with no sound, so I decided to list t here anyway. Maybe I did something wrong in the instalation or so.
2) I did not find out how to get to the dualboot menu. I think I was able to choose Mangoplayer or Rockbox when i first booted it...but from then on, pushing the ON button automatically boots Rockbox. I tried several button combinations at boot time, but none did open the dualboot menu.
3) Rockbox did not show the music files on the SD card. After a while, I found out that the contents of the SD card should be listed under Files>mnt and NOT "sdcard", but still...the folder was shown as empty. I took out the SD and plugged it directly into my PC - and all the music files are shown. The original iBasso firmware also detects and plays all the contents.
As a result, for now, I have reverted to the original firmware. In the meantime, I thought I completely bricked the device, but luckily I succeeded in the uninstallation. I had underestimated how much of a problem the lack of real and complete documentation is for a newbie like me.
Sooo...do you have any idea where the problems came from? Particularly issues #2 and #3?
Thanks ever so much in advance,
RBNB
-
[...]
1) I didn't get any sound. At first there was a crackling in my headphones, but then nothing. HOWEVER, this might be a result of my own stupidity. I am not sure if I didn't accidentally plug my headphones into the COAX out of the DX50.
[...]
Well, try again. Make sure to use the headphone out. Report back, if there is still no sound while using the headphone out.
[...]
2) I did not find out how to get to the dualboot menu. I think I was able to choose Mangoplayer or Rockbox when i first booted it...but from then on, pushing the ON button automatically boots Rockbox. I tried several button combinations at boot time, but none did open the dualboot menu.
[...]
To start the chooser menu, engage the hold switch (the upper/locked position) and then turn on the device.
[...]
3) Rockbox did not show the music files on the SD card. After a while, I found out that the contents of the SD card should be listed under Files>mnt and NOT "sdcard", but still...the folder was shown as empty. I took out the SD and plugged it directly into my PC - and all the music files are shown. The original iBasso firmware also detects and plays all the contents.
[...]
Internal storage: /mnt/sdcard/.
SD Card: /mnt/external_sd/.
HTH.
-
Thank you very much, ArgelErx. Your reply is a huge help already.
I will work my way through the installation process again. Now that I finally know how to open the DualBoot menu, there is definitely nothing wrong with having both firmwares installed on the device.
The thing with the SD card will remain a problem, though. I have DEFINITELY opened Files>mnt>external_sd, and it was empty. I tried to format the sd card from the menu I can open by pressing Volume Up+Power (the CWM menu or what its name is), and it also didn't help. What confused me: after I formatted the SD card from that menu, when I connected the SD to my computer, my music files were still on it. I checked the card, it's FAT32 formatted, so that shouldn't be an issue...right? Is there any other thing I might have forgotten and which might cause these SD problems?
Again, thanks a lot.
RBNB
EDIT: For some reason, I can't get to installing Rockbox anymore. I used the RKbatch tool, and flashed the update.img to the device. From the CWM recovery menu, I decided to try the other .zip file (the one by isergachev), but it did not work...I thought maybe it doesn't work with iBasso FW 1.5. Then, I put cholero's .zip on the SD card and tried to install it...but I received the same error as I did with the isergachev file. It would not work anymore. I couldn't do anything but revert to the stock FW using RKbatch...AGAIN. Damn, I really don't know what went wrong this time!
-
[...]
The thing with the SD card will remain a problem, though. I have DEFINITELY opened Files>mnt>external_sd, and it was empty. I tried to format the sd card from the menu I can open by pressing Volume Up+Power (the CWM menu or what its name is), and it also didn't help. What confused me: after I formatted the SD card from that menu, when I connected the SD to my computer, my music files were still on it. I checked the card, it's FAT32 formatted, so that shouldn't be an issue...right? Is there any other thing I might have forgotten and which might cause these SD problems?
[...]
Using CWM for more than flashing and factory reset might be dangerous. I've used the two afore mention functions (and had a backup plan in case of bricking the device) but i would not rely on anything else. We do not know how thouroughly the creators of this CWM have tested their creation.
I've formated by SD Card on my PC (gparted, Linux) with FAT32. It works as expected ...
As for your card, if it works with the original firmware, than it should work with Rockbox. After all its just a different programm running on the same OS using the same access methods.
There are some settings in Rockbox that influence what files are shown (Settings -> Files IIRC) and AFAIK ther are certain file names that are not shown at all (starting with '.' for example).
[...]
EDIT: For some reason, I can't get to installing Rockbox anymore. I used the RKbatch tool, and flashed the update.img to the device. From the CWM recovery menu, I decided to try the other .zip file (the one by isergachev), but it did not work...I thought maybe it doesn't work with iBasso FW 1.5. Then, I put cholero's .zip on the SD card and tried to install it...but I received the same error as I did with the isergachev file. It would not work anymore. I couldn't do anything but revert to the stock FW using RKbatch...AGAIN. Damn, I really don't know what went wrong this time!
If you used the description on head-fi (http://www.head-fi.org/t/709855/rockbox-for-ibasso-dx50-cwm-recovery-latest-update-2014-09-15) follow it exactly. Start with clean original firmware version 1.5. Use choleros image.
I did not use RKbatch tool.
But its been a while since i did this. I am currently on development version where most of the flashing is not necessary anymore. But thats for a upcoming release ...
-
You shouldn't have to use RKbatch tool at all for installation of rockbox, etc. It's only needed in case of extreme fubarness.
-
Thanks for your feedback, guys.
I actually indeed used the description posted on head-fi. The thing is: I'm having trouble to UNDERSTAND what I have to do there. I used the RKbatch method because it says there "this one MUST work". The step-by-step guide (with all of its alternative methods and stuff) is pretty confusing for a noob like me. I mean I have been using RB before, and I have installed it on a "problematic" device (iPod Classic), but when it says "only if you have CWM" or "only if you have original recovery"...I simply don't KNOW. Which case applies for me now? Instead of RKbatch, shall I use 4b. or 4c.? I was afraid that if I use the wrong method, I might end up bricking the DX50, so I picked RKbatch.
Thanks in advance,
RBNB
-
ArgelErx did a complete code cleanup of the port. If someone wants to test it, see the head-fi forum for details:
http://www.head-fi.org/t/709855/rockbox-for-ibasso-dx50-cwm-recovery-latest-update-2014-09-15/1275#post_11053921 (http://www.head-fi.org/t/709855/rockbox-for-ibasso-dx50-cwm-recovery-latest-update-2014-09-15/1275#post_11053921)
-
RBNB, you should really pursue this on the Headfi forum page - this is the wrong place for this.
-
i use my ibasso dx50 w/ rockbox for reading ebooks which i convert into txt format, i accidentally made a few bookmarks (i think by pressing power and raise volume buttons together, and i can't figure out how to remove them, can s/o please help me?
-
Hey All,
I am an embedded firmware developer with a masters in DSP and recently purchased a DX90 as it were being lauded on HeadFi especially with Rockbox and I am all about music :D Installed the latest greatest port and for the most part it works well. The reason I am here is because I would like to get started contributing to this effort to make the DX90 por better. One thing I really need to fix (atleast for my own device) is the sensitivity of the touch screen. Just doesn't work very well among a few other things I would like to tweak.
I am on a Mac and tried installing the cross compiler etc according to the instructions in the wiki and couldn't get it to build so I went into my Windows 8.1 VM under parallels and installed Cygwin 64-bit and again, no luck with it erroring out halfway through building the cross-compiler. Installed Cygwin 32-bit and bingo, cross-compiler installed... very good, feeling lucky. Next step I assume is to build RB however the wiki mentions (and upon trying to run configure) needing the Android NDK but states Android 16. I have never worked with android or the NDK and so excuse my ignorance but on the website for installing Android NDK i see no version 16, only versions up to 10d. Would someone please mind to nudge me toward the proper version of the NDK to install?
-
Could anyone point me to the appropriate Android NDK download needed to build this using the latest 32-bit cygwin? Google only has the latest 10something up and I wasn't aware of whether or not that would work as it seems that have totally changed compilers and everything since v10 and on. Someone mentioned 9d but I can't find the 32-bit installer. I am trying to build for DX-90 so that I can dig in and fix the touchscreen sensitivity.
I am an experienced firmware developer and would like to contribute to rockbox for the DX-90. Any help getting rolling would be appreciated.
-
I'm not sure if its possible to compile rockbox for the DX50 in cygwin. It was at one point, but we dropped support for it in favor of Linux/Mac/Virtualbox.
Regarding android, I think you can just use the current sdk/ndk, but the wiki says at least version 16 is needed (Jellybean).
Edit: Merged your other post. Regarding your error on the Mac, most likely this is because you need to install gcc. Apple no longer bundles it with MacOS, so in recent versions rockboxdev will fail. Here is a cached version of some instructions for installing gcc on the Mac:
http://webcache.googleusercontent.com/search?q=cache:0OtvzgZOJ7sJ:https://wiki.helsinki.fi/display/HUGG/Installing%2Bthe%2BGNU%2Bcompilers%2Bon%2BMac%2BOS%2BX+&cd=2&hl=en&ct=clnk&gl=us
-
First I tried the Mac with proper gcc and all required packages (using MacPorts) and it failed to build the cross-compiler with a ton of fundamental issues that would have required me to go back to some ancient version of gcc perhaps, no thanks.
Second I thought, having already a Win8 parallels VM for work I would just fire up Cygwin. Started with Cygwin 64-bit, all the packages, again erring out on cross-compiler build complaining about 64-bit something. Switched to 32-bit Cygwin and the cross-compiler built but then I struggled with finding an Android NDK that would work with it and no luck there, trying both 9 and 10.
Finally decided to just install Ubuntu since it seems everyone else is using that. Started with 64-bit install and boom cross-compiler no problem. Downloaded latest NDK 10e and it would have none of it. Took some time to find a url for an older version 9d someone else mentioned using from headfi but I didn't realize the link I found were 32-bit until it complained about not being impressed about 64-bit. Still unaware what exactly was wrong I assumed I needed Ubuntu 32-bit, lol ;) Halfway through installing that I finally eureka'd and appended _64 to the 9d NDK url and whammo! Finally built!
So either I am entirely useless or you really shouldn't even waste your time with anything but Linux for Rockbox. Moreover it also seems incompatible with anything Android NDK 10+, so you will need to use NDK 9. Here is the url I eventually used to get NDK 9d since they no longer post links for older versions...
http://dl.google.com/android/ndk/android-ndk-r9d-linux-x86_64.tar.bz2
Someone should really archive this file for future developers incase they pull it or better yet upgrade Rockbox to work with NDK 10+. It was all quite a confusing process but I finally arrived ;) Now what? lol
-
Any help with the process of loading the code and debugging it over usb onto a DX-90 that is already running the Lurker/Rockbox 2.2.0 build would be greatly appreciated so I do not brick my device trying to get this thing running. As soon as I get it running and debugging I will crack into the touchscreen driver and see what I can do. I will also take a look at the i2c driver as it appears from the bug tracker there are timing issues with it causing clicking in the right ear while reading RTC and battery?
-
First I tried the Mac with proper gcc and all required packages (using MacPorts) and it failed to build the cross-compiler with a ton of fundamental issues that would have required me to go back to some ancient version of gcc perhaps, no thanks.
As far as I know, any modern version will work. I used 4.9.2 from the link above on 10.10 and it built normally.
-
Yeah didn't work for me.
-
mounted the DX-90 as USB drive under Ubuntu and was able to simply drag and drop the .rockbox folder over and it worked! Ok, now I got something I can work with. Sorting out the debugger next would be nice.
-
just submitted my touchscreen fixes to one of the devs over on head-fi. hopefully finds it's way into the real deal eventually ;D
-
Here you go
http://gerrit.rockbox.org/r/#/c/1192/ (http://gerrit.rockbox.org/r/#/c/1192/)
Thanks a lot! It makes the Touchscreen much more usable :)
-
8)
-
Can anybody confirm that the crossfeed function is working on the iBasso? This is essential for me and I wouldn't buy an expensive player if it has no crossfeed. With my Android phone this function is available but has no effect at all. That's why I'm asking. Thanks.
-
I can. The port is fully functional includung all dsp effects like crossfeed.
-
Thank you for this confirmation! Now I'll go to buy one ;)
-
I've had so many issues with my DX90 Rockbox, if I didn't lose my hair already i'd try to pull it all out hah.
- Playlists are annoying and don't work right, M3u/8 are not supported fully without serious bugs and problems
- Player eats battery power like no tomorrow with no EQ or filters on, Mango lasts twice as long.
- My rockboxing was stable for a few days until today, for some reason it just flashes constantly. Can't uninstall it, it seems. Can't get memory on the sd or internal to appear after connecting to the usb and pc, no bootloader to uninstall it that way.
Pretty much rendered un re-sellable now if this cannot be fixed.
-
I tried to put the latest daily build on my device and I can use the file viewer and plugins, but I can't seem to do anything else like, play music, change settings etc. is this a problem w/ the build, or the firmware/bootloader file, or maybe I didn't install properly?
-
Hi,
sorry for the long delay, I struggled to actually build for that target. Here are some builds for you to try and report (*)
- HEAD (7a12e796a): https://www.dropbox.com/s/ynkf6ksb46lkqfc/rockbox_dx50_7a12e796a.zip?dl=0 (https://www.dropbox.com/s/ynkf6ksb46lkqfc/rockbox_dx50_7a12e796a.zip?dl=0)
- Bisect #1 (eefc7c73): https://www.dropbox.com/s/zr0zlgkl3q7ydpq/rockbox_dx50_eefc7c73.zip?dl=0 (https://www.dropbox.com/s/zr0zlgkl3q7ydpq/rockbox_dx50_eefc7c73.zip?dl=0)
- DX50 NDK-only commit(dbabd0d9c): https://www.dropbox.com/s/tzbu84z1qkx8evi/rockbox_dx50_dbabd0d9c.zip?dl=0 (https://www.dropbox.com/s/tzbu84z1qkx8evi/rockbox_dx50_dbabd0d9c.zip?dl=0)
DISCLAIMER: I do not own the device and no nothing about it, I am just helping to bisect
(*) I couldn't compile the expect android toolchain, I had to apply
http://gerrit.rockbox.org/r/#/c/1296/1 (http://gerrit.rockbox.org/r/#/c/1296/1). I then ran into further configure bugs which means I had to backport some commits. Hopefully this should not introduce any (further) bug.
EDIT: current state of bisect:
- HEAD (7a12e796a): https://www.dropbox.com/s/ynkf6ksb46lkqfc/rockbox_dx50_7a12e796a.zip?dl=0 (https://www.dropbox.com/s/ynkf6ksb46lkqfc/rockbox_dx50_7a12e796a.zip?dl=0) -> BAD
- Bisect #4 (71e3f6c): https://www.dropbox.com/s/91k3k788xft39wh/rockbox_dx50_71e3f6c.zip?dl=0 (https://www.dropbox.com/s/91k3k788xft39wh/rockbox_dx50_71e3f6c.zip?dl=0) -> BAD
- Bisect #5 (055e2115): https://www.dropbox.com/s/4jyw83g0lyu2lje/rockbox_dx50_055e2115.zip?dl=0 (https://www.dropbox.com/s/4jyw83g0lyu2lje/rockbox_dx50_055e2115.zip?dl=0) ->BAD
- Bisect #6 (12bc24ad): https://www.dropbox.com/s/k437sebe9l2o13a/rockbox_dx50_12bc24ad.zip?dl=0 (https://www.dropbox.com/s/k437sebe9l2o13a/rockbox_dx50_12bc24ad.zip?dl=0) -> BAD
- Bisect #9 (aced667): https://www.dropbox.com/s/hcvptgy2cu4hjmy/rockbox_dx50_aced667.zip?dl=0 (https://www.dropbox.com/s/hcvptgy2cu4hjmy/rockbox_dx50_aced667.zip?dl=0) -> BAD
- Bisect #10 (5c96889): https://www.dropbox.com/s/5wve57kule0zb44/rockbox_dx50_5c96889.zip?dl=0 (https://www.dropbox.com/s/5wve57kule0zb44/rockbox_dx50_5c96889.zip?dl=0) -> BAD
- Bisect #8 (52af55e): https://www.dropbox.com/s/kbscaz31v4oaiq4/rockbox_dx50_52af55e.zip?dl=0 (https://www.dropbox.com/s/kbscaz31v4oaiq4/rockbox_dx50_52af55e.zip?dl=0) ->GOOD
- Bisect #7 (ff08c52): https://www.dropbox.com/s/2mkxwpglymvexuv/rockbox_dx50_ff08c52.zip?dl=0 (https://www.dropbox.com/s/2mkxwpglymvexuv/rockbox_dx50_ff08c52.zip?dl=0) -> GOOD
- Bisect #3 (ec4fa03): https://www.dropbox.com/s/msxz5nzv6pkdytn/rockbox_dx50_ec4fa03.zip?dl=0 (https://www.dropbox.com/s/msxz5nzv6pkdytn/rockbox_dx50_ec4fa03.zip?dl=0) -> GOOD
- Bisect #2 (acc3ef3): https://www.dropbox.com/s/itbe5ss1oe6c4rk/rockbox_dx50_acc3ef3.zip?dl=0 (https://www.dropbox.com/s/itbe5ss1oe6c4rk/rockbox_dx50_acc3ef3.zip?dl=0) -> GOOD
- Bisect #1 (eefc7c73): https://www.dropbox.com/s/zr0zlgkl3q7ydpq/rockbox_dx50_eefc7c73.zip?dl=0 (https://www.dropbox.com/s/zr0zlgkl3q7ydpq/rockbox_dx50_eefc7c73.zip?dl=0) -> GOOD
- DX50 NDK-only commit(dbabd0d9c): https://www.dropbox.com/s/tzbu84z1qkx8evi/rockbox_dx50_dbabd0d9c.zip?dl=0 (https://www.dropbox.com/s/tzbu84z1qkx8evi/rockbox_dx50_dbabd0d9c.zip?dl=0) -> GOOD
I am going to ignore the tag building bug you mentioned for now, only one problem at a time :)[/list]
It appears the bad commit is https://git.rockbox.org/?p=rockbox.git;a=commit;h=5c96889 (https://git.rockbox.org/?p=rockbox.git;a=commit;h=5c96889), which is very surprising. Assuming the bisect went well, it probably means some of the DX50 may rely on some undefined/undocumented behavior of the print function, I guess when messing up with sysfs. I'll try to look at the code to find where, but it's potentially a lot of code to search.
-
I tried some basics on all 4 builds:
1) HEAD (7a12e796a): had the same problem.
2) Bisect #2 (acc3ef3): seems to work very well, it does not support the plugins sgt-loopy or sgt-palisade.
The pixel painter plugin doesn't either work, but the flyspray says that it wasn't configured for touchscreen
devices so I assume that that still hasn't been done.
3) Bisect #1 (eefc7c73): much the same as bisect #2 but it doesn't support sgt-mines, and does not have the
extensive help for all the sgt plugins.
4) DX50 NDK-only commit(dbabd0d9c): this works, but does not support the new plugins.
Thank you so much.
EDIT: I tried building a database (using bisect 2), when it says 'updating in background' the screen gets stuck, it continues building the database, but I can't continue browsing until it completes the process.
bisect 3 seems the same as bisect 2
bisect 4: same as head
bisect 5: same as head
bisect 6: same as head
bisect 7: same as bisect 2, but it does support the plugins sgt-loopy and sgt-palisade
EDIT: for some reason these 2 plugins only work on one of my devices w/ this build
bisect 8: same as bisect 7
bisect 9: same as head
bisect 10: same as head
-
Hello ,
i've got the same bugs on my Ibasso DX50
With the latest build that don't work
Did you manage to run the latest builds? ?
-
I've tried using various usb otg cables and it seems like the ones which split into multiple ports don't work. Is this limited by the hardware or the firmware?
-
Hello ,
Is someone has a ROCKBOX port of 2018 that work on DX50 ?
i've got a port of ROCKBOX 07.11.2017 that is work very well
(so not a hardware problem)
I tried with the firmware dual boot 1.93 and the firmware dual boot 1.95 and i have the same problem
(so not a firmware problem)
So i believe it's a port problem ......
-
The current build seems to work, probably thanks to patch d8ce84c. The problem with building the database in the background still exists, though.
EDIT: The lua apps need to be updated with the new rb.touchscreen_mode(mode) code, as per this thread. http://forums.rockbox.org/index.php/topic,52541.0.html (http://forums.rockbox.org/index.php/topic,52541.0.html)
-
Hello ,
thank you very much for the info
IT'S WORKING NOW !!!!!
I advise you to put the theme "arc en ciel" to correct the layout in the main menu
After you can put back the theme you wish , the main menu will remain fixed