Hello,
Thanks all for the votes. This was also to have feedback on the number of people interested in this project. thanks! 
I have good news about my recent development.
The RetroArch is almost ready, I just want to do some tests before making it available. The main points are:
- Screen Brightness control on the main menu.
- Shutdown, and restart on the main menu.
- wifi connection and management.
- Bluetooth management.
- Hardware monitoring option (temperature, and CPU frequency).
- The on-screen keyboard from RetroArch works with the GameShell gamepad for text entry (so you can entry your wifi password).
On my quest to make all the modifications above, I needed to use connman daemon to manage the wifi connection, since RetroArch already has a drive using it to manage wifi. After spending a lot of time fixing all the problems and finally having the wifi working with RetroArch, I found that the RetroArch team released an experimental driver for Bluetooth as well, so I decided to implement it. On my way of implementing the new BT driver, I found that BT stopped working completely. After days of trying to find the problem, I found that connman disables the BT 
.
To find out what was happening to the BT, I tried all sorts of things because even after removing connman I couldn’t get BT working again, so connman was not the obvious problem especially because I modified a lot the image at this stage. In this journey, I tried different ways to upload the BT firmware to the BT chip, compiled the firmware utility, read a lot about the UART implemented in our SOC, understand how everything was connected electrically and I finally saw that the only problem was that connman was blocking something even after complete removal. So a
rfkill unblock all
did the job and I was able to get BT working again.
The thing was that after all the learning about how everything was working and the BT<->SOC connection, I was convinced that there is no hardware limitation to have higher baudrates and make sound over BT possible. I managed to use a kernel driver to upload the BT firmware to the chip which is better than using the utility brcm_patchram_plus we have actually. The only thing that was bothering me was that I couldn’t increase the baudrate no matter what I tried: new brcm_patchram_plus compiled, original, hciattach utility, kernel driver, different UART configuration new kernel patches to change clock speeds …
I finally found (trial and error) that our BT chip works only with 3 different baudrates: 115200 bps, 500000 bps, and 1.5 Mbps. The 115200 bps is the default and it is what we have normally. 115200 bps is not enough for smooth audio over BT (the audio is stuttering), but 500000 bps, and 1.5 Mbps are enough. I’m actually testing 1.5 Mbps with audio and it is working perfectly. I had problems getting a stable connection when trying brcm_patchram_plus and 1.5 Mbps, but using the kernel driver seems to be working fine.
So even nobody voted for having audio over BT we will have it 
It is experimental, and I still don’t know the stability or how well I managed to implement it, but I took it personally because of other problems, and because brcm_patchram_plus was the ugly part of my image.
Regarding the audio over HDMI, I will wait before going on this adventure. It is likely the driver developer will make it happen, and I’m sure it will be much better than what I could do. So, for next we should have:
- Custom RetroArch
- Audio over BT.
No guarantees yet because I’m testing it. The BT audio is a possibility, but maybe the user needs to tweak a bit since we still have problems with the A2DP profile in Linux. If you are lucky everything will just work, otherwise, a good source of learning to have the A2DP set correctly can be found here:
https://wiki.archlinux.org/index.php/Bluetooth_headset#Switch_between_HSP/HFP_and_A2DP_setting
I’ll try to release a new image in some weeks.
BR