Project Roadmap — What to work on next?

[noisetta]

Now that the project has some renewed momentum and another contributor, it feels like a good time to map out where we want to take this.

What we have so far:

• Working unpack/repack toolchain for R3 Pro II firmware
• Documented OTA format (chunk chain system, ISO structure, squashfs parameters)
• QEMU emulation setup (partial - see note below)
• Working Arabic font mod as proof of concept
• Windows support

A note on QEMU:
The QEMU setup is currently incomplete. QEMU doesn't natively support any board types that resemble the HiBy devices, so a custom board implementation needs to be added to QEMU itself. This work was started by a contributor but is currently stalled as it's quite challenging. If anyone has experience with QEMU board emulation or embedded systems this would be a great area to contribute. For now QEMU should be considered a long term research effort rather than a working tool.

Potential directions — roughly in order of difficulty:

• ADB enablement — the daemon is already on the device, just needs to be activated. Probably the highest impact next step as it opens live shell access for real-time experimentation
• Additional language/font support — Persian, Urdu, Hebrew, etc., other scripts
• Custom themes — the theme system is config-driven, may be approachable without binary patching
• Ingenic development tools — hosting solution needed for the 11GB toolchain (archive.org being looked into)
• R1 support — extending the toolchain to other HiBy devices
• hiby_player decompilation — the big long term goal, currently a brick wall. The binary is large, proprietary, and has no symbols. QEMU emulation would significantly help here which is another reason to prioritize getting that unblocked
• QEMU board support — prerequisite for proper emulation and would greatly accelerate hiby_player reverse engineering

Open question: Where should we focus first?
Tagging @Tartarus6 and anyone else following the project — all input welcome.

[Tartarus6]

@noisetta
I think that making a custom firmware that includes the enabled ADB would be good. I'd want to do some testing on how it works in practice, since while I was testing it, it was sometimes connecting and sometimes not.

Another big thing we can do would be improving RockBox for the Hiby OS devices. Someone already made a version of RockBox that can run on the Hiby OS devices, but it does not support bluetooth or wifi.
I think that we could add it, since we have the firmware cracked already and have access to the device-specific drivers that hiby_player uses.

[Tartarus6]

Here is a page on RockBox that explains the current state of bluetooth support, why it hasn't been added, and how it might be added.
https://www.rockbox.org/wiki/BluetoothFAQ.html

[noisetta]

@Tartarus6
Totally agree — ADB first. The inconsistent connection is probably because it needs proper initialization at boot via an init script rather than being triggered manually. That should make it reliable.

On RockBox — I looked into the Bluetooth FAQ and the key part for us is that Bluetooth is possible on hosted ports running on top of the manufacturer OS, which is exactly what the HiBy port appears to be. We already have BlueALSA working on the device so the missing piece is just the integration code bridging RockBox to HiBy's Bluetooth stack.

I also checked the R3 Pro II RockBox build info — it explicitly shows CPU: hosted and has a hibylinux feature flag which confirms it. Do you know where the HiBy RockBox port source lives? That's the next piece we need.

[Tartarus6]

i was looking for the source earlier. it's a bit hard to find

i think the full rockbox repo is located here. and there's also a read-only mirror on github here.

I can look into rockbox more deeply if you want to focus on ADB streamlining.

[greenturtle537]

@noisetta Looping you in on this, but I am the current lead on the qemu board integration which requires that we add in support for the family of SoCs used by the HiBy. I am focusing my efforts entirely on it for the time being, but have not had the time in my life required to make notable progress on support for it.

[noisetta]

Thanks for looping me in and for the context. That's genuinely complex work and I appreciate you keeping it moving even with limited time. No pressure on timeline — having someone with focused knowledge on the QEMU board integration is what this project needs for that piece. If there's anything on the firmware/OS side that would help unblock your work — partition layout details, MTD structure, boot sequence documentation — feel free to reach out. Happy to contribute whatever context I can from the reverse engineering side.

[Jepl4r]

• ADB enablement — the daemon is already on the device, just needs to be activated. Probably the highest impact next step as it opens live shell access for real-time experimentation

Enabling ADB by renaming T90adb to S90adb seems to break USB storage mode.

I couldn't get the SD Card to show on MacOS or Windows when ADB was enabled.

[Tartarus6]

@Jepl4r from my work so far decompiling, I think it is probably in there somewhere

they probably just changed a tiny part so that it wouldn't work

I think I can probably just change it back

but I'll have to look more into it

[Jepl4r]

@Tartarus6 If that's the case, then yes, you should be able to restore it.
The hard part will definitely be figuring out how it was modified.

[Tartarus6]

yeah

[noisetta]

@Tartarus6 it looks like the toggle function and status icon are already there, they just need to be linked up with the UI. Do you have enough context from the decompilation to figure out how other settings toggles call their respective functions? If we can find the pattern for how something like the WiFi toggle works, we could replicate it for ADB.

[Tartarus6]

@noisetta I should be able to figure it out

not gonna be a super quick and easy thing. but it seems probably achievable

[Jepl4r]

I've modified the theme, is anyone interested?
It's a basic modification; I just swapped out the icon .png files and edited the hiby_launcher_apps.view file to display the rounded rectangles like the other pages, but it's a start.
I think the main page layout can only be changed by patching hiby_player, since the layout seems to be hardcoded.

[Tartarus6]

@noisetta not sure how we want to go forward with providing and organizing custom firmwares

since this repo doesn't have any, and is mainly focused on the tools for cracking the firmware, would it make sense to put the custom firmwares on your repo instead?

[Jepl4r]

Yeah, probably better to put it in the other repo if this is focused on cracking the firmware

[noisetta]

That looks great, definitely interested! Even basic modifications like this are valuable as a proof of concept that the UI can be customized without touching the binary.

[noisetta]

@Jepl4r ; Your observation about the main page layout being hardcoded in hiby_player matches what we found during reverse engineering — the binary references layout files directly and some elements appear to be hardcoded. However the .view and .dlg files in /usr/resource/layout/ are JSON-based and config-driven, so there's likely more that can be modified without binary patching than it initially appears.

On the repo organization front — we were just discussing this. The plan is to use hiby_os_crack purely for tools and documentation, and use hiby-r3proii-custom-firmware as the home for actual firmware modifications and releases. I'm also thinking of renaming it to something more general like hiby-custom-firmware to cover all HiBy devices as the project expands.

Your GUI mod would be a perfect fit for that repo — we could set up a themes/ directory as a home for community UI modifications so others can build on your work. Would you be willing to share your modified files as a PR there once we get the structure sorted?

Also — what tools are you using to edit the .view files? Just a text editor or something else?

[Jepl4r]

@noisetta Will happily make a PR when I'm finished modifying the theme.

As for how I modified the .view files I just used the MacOS text editor.

[noisetta]

For build v1.2 which combines the Unicode font support, updated sorting patch, and Unified Theme, I wanted to get everyone's thoughts on how to structure the release.

We have a few options:

1. Single firmware — Unicode font + sorting patch + Unified Theme (Sorting variant) all in one
2. Two variants — a standard build (Unicode font + Normal theme, stock hiby_player) and a sorting build (Unicode font + Sorting theme + patched hiby_player)
3. Modular — firmware with just Unicode font + sorting patch, theme distributed separately as manual install files

One thing worth considering is whether the sorting patch affects Chinese Pinyin sorting for users with large Chinese music libraries — if it does, some users may specifically want to avoid it.

Thoughts?

[Jepl4r]

@noisetta Never had a bootloop issue with that type of parameter. Even RockBox uses it: https://github.com/Rockbox/rockbox/blob/master/tools/r1_patcher/r1_patcher.sh
Note: this script is used for the R3 Pro II too.

The folders will be removed, I just created the branch using the whole folder I was working on.

When making a release you can bundle the folders needed for the script to work.

As for the macOS app, even I don't know if we should include it, the script should already be easy enough to understand for the average user.

[noisetta]

Fair point on the squashfs parameters , the main thing to verify is the ISO structure, the RockBox script puts ota_config.in at the same level as ota_v0/ inside the image which is correct, as long as the tool produces that same structure we should be good.

The bundled release approach makes total sense, keep the repo clean and package everything needed into a zip for each release. On the macOS app, the script is probably sufficient for most users, but if you want to include it a separate release asset would be cleaner than tracking it in the repo. Either way, your call since you built it :) Looking forward to the PR!

[Jepl4r]

I ditched the macOS app, now there's only the script which I changed as you suggested before.

The Firmware structure is correct, there are no problems with it. I'm actually using it to test some more theme related stuff I'm working on.

Edit: I already made the PR.

[Jepl4r]

Here's a sneak peak of what I'm doing.

[noisetta]

That looks awesome. Exciting stuff!

[Jepl4r]

@noisetta @Tartarus6 This might be interesting.

I modified the wifi_on script and now when activating WiFi the device doesn't lag like crazy like it did before.
wifi_on.sh

Btw, do we know what script initialises the Receive songs via Wi-Fi feature? Sometimes it doesn't work, maybe we can modify it to be more reliable.

[Jepl4r]

found out the receive songs feature doesn't have a script. the hiby_player binary starts thttpd when clicking on it.

[Tartarus6]

weird. i havent really noticed that problem. though, i just leave wifi on, so im not really ever toggling it.

i do, however, notice some serious lag issues sometimes when enabling or disabling bluetooth. Sometimes itll freeze for like 20 seconds.

[Jepl4r]

Yeah, sometimes I need to force shutdown for it to unfreeze. Only happens with bluetooth.

[noisetta]

Yea, i'm noticing issues with bluetooth too, mainly lag.

[noisetta]

Quick roadmap update to reflect where things stand:

Recently completed:

• ADB working via easter egg (tap About 10x) — full root shell access confirmed
• Unified Theme with 3 variants including full 13 language support
• Database Manager — load/save library via Settings
• PC Database Updater — Python script + macOS GUI
• WiFi toggle lag fix (@Jepl4r)
• Custom firmware identifier (1.4+ in About page)
• Image cache investigated and confirmed not worth enabling — causes audio lag due to CPU/RAM constraints

In progress:

• More theme refinements — @Jepl4r working on additional system prompts and balance output icon
• QEMU board support — @greenturtle537 working on Ingenic X1600, stalled pending available time
• RockBox Bluetooth — @Tartarus6 investigating

Next focus:

• Bluetooth lag debugging — affects everyone, now achievable with ADB
• Linux AppImage for Database Updater GUI
• ADB documentation in hiby_os_crack (if not already there)

The project has come a long way — great work everyone!

[Jepl4r]

Regarding Bluetooth support with RockBox someone posted this one the HiBy subreddit

https://www.reddit.com/r/Hiby/s/jt21wn7gsS

Edit: you already found out lol

[noisetta]

Oh that's right, I did see that on Reddit!
It's nice to see people are interested in working on improvements.
I think @Tartarus6 reached out to them.

[Tartarus6]

yeah, I replied on Reddit

I'll see if they respond

[Jepl4r]

@noisetta Inside the config.json file there's this line {"most_played":0},. When changed to 1 a new menu voice appears inside the playlists menu showing all the most played songs with how many times.

I'm already testing it, could you do the same (no pressure) to see if it works correctly? If it does we could enable it for next release.

[noisetta]

Confirmed working on my end! The Most Played playlist shows up correctly in the Playlists menu and populates with play counts. Simple config flag, no issues. Let's include it in v1.5. Great idea.

[Jepl4r]

Alright, I'll fix the delete list icon on the top right first, it's placed too close to the list