Miyoo Mini, gaming handheld with ssd202d

[asoderq]

Hi,

I just wanted to make you aware that there is a tiny gaming handheld in the makings that uses the ssd202d. It should be released relatively soon. The only other thing I know about it is that it is supposed to have a 640x480 display.

[fifteenhex]

Thanks for the heads up. Hopefully I can get one of these and get the display etc working.

[asoderq]

I will post a link to aliexpress when it is out. I am following it quite closely.

[fifteenhex]

Thanks! I'll keep an eye on taobao too. I guess I need to try harder at getting sound working in my kernel now. :)

[fifteenhex]

Found this after googling a bit:

https://ezbuy.sg/product/51000217825092.html

If that price is right and USD then the price is pretty good.

[fifteenhex]

scratch that. Looks like it's a different thing :(

[asoderq]

That is the predecessor, called Bittboy. It uses an Allwinner F1Cxxx series. I am not sure which one.

[asoderq]

I realized that the SSD202D doesn't have a USB 'device' port, which is inconvenient for app development. Other similar devices I played around with uses this for Ethernet over USB so that you can remotely login with just a USB cable hooked to your computer. I think the SSD210 or SSD212 would have been a wiser choice in this respect. Alternatively if they exposed an USB 'host' port that could be used for Ethernet or WiFi dongle when developing. I am guessing the USB-C is only for charging, but I am not sure. Do you know if it is possible in the USB standard to perform both charging function and USB 'host' on single connector?

[nistvan86]

Are there any advancements with data transfer over USB? Or this is also blocked by the fact that we don't have any open-source firmware / kernel available for the Miyoo Mini?
If it turns out that USB is not usable for slave functionality, would it be possible to use some kind of SDIO interface in place of the SD card to do the same?

[fifteenhex]

The usb data signals are connected to the USB connector as far as I can tell.
If you can work out how to get the usb gadget part of the usb controller working you could have it talk MTP or whatever.

[nistvan86]

But that needs a custom kernel I presume which we cannot have because the firmware is locked and no source available.

[samueldr]

While we don't have the sources for that particular product, other SSD202D trees can be used to do stuff like producing kernel modules for features that are not available.

I don't have an example handy, and you'll have to draw the rest of the owl, but you can build a single module (I did loop.ko), as long as you figure out the correct configuration that produces the same data structures. The configuration is not part of the kernel, no /proc/config[.gz] and no IKCONFIG present either, so that is the main challenge. With loop.ko I had to futz around with ghidra trying to guesstimate which data structures were wrong until the kernel module stopped causing kernel panics.

You will need to solder on a UART connector though, or else debugging this will be almost impossible :).

Though, with that said, I'm not positive the existing kernel modules from the vendor dumps had what was needed for gadget mode to work... But I don't remember if I actually looked.

Oh, to help kickstart your journey: I was using https://github.com/linux-chenxing/linux-ssc325/tree/979122be45d470e959c2245c996fa93dea10069b as a starting point to build additional modules.

[fifteenhex]

The kernel they used seems to be one of the ssd202d ones we have..

but we could actually get mainline running with a bit of help..

https://twitter.com/linux_chenxing/status/1494903575025446916

[asoderq]

A relatively new video about Miyoo Mini:
https://www.bilibili.com/video/BV1Wh411b7L6

Apparently they have put a PSP emulator on it, I didn't even know that there existed a software renderer PPSSPP.

[asoderq]

No idea why they mention a bunch of other SoCs in the video but not the SSD202D.

[asoderq]

This video might just be speculations from someone. Best to take it with a grain of salt.

[asoderq]

It has been released now, and is available on aliexpress. Although I don't have taobao account, I heard it was sold out there. Here is a link to ali:
https://www.aliexpress.com/item/1005003611677275.html
but as usually you may find it elsewhere.

[fifteenhex]

Thanks, Ordering some now..
Couldn't find them on taobao but I guess taobao isn't a good way to get them anyway as the agents usually refuse to ship stuff with batteries.

[asoderq]

I just noticed, be aware that this seller doesn't have any reviews...

[fifteenhex]

Getting money back from sellers that don't deliver is basically the only thing paypal is useful for these days :D.

[asoderq]

When you receive it please post high res PCB pictures :)

[fifteenhex]

Sure. I'll probably take back and front scans to overlay and trace out, write a wiki page with where things are wired up and then write a devicetree.

[asoderq]

A video about the miyoo mini:
https://www.youtube.com/watch?v=lIYXE1-OPDI&ab_channel=AlwaysBeFun

[asoderq]

Follow up video, apparently he bricked his miyoo mini with an update:
https://www.youtube.com/watch?v=SNcezdyFg1Y&t=1s&ab_channel=AlwaysBeFun

[fifteenhex]

He's getting a splash screen so that suggests it's getting to u-boot at least. I suspect it's possible to unbrick it without replacing the chip like he mentions..

First thing I'll do is dump out the original firmware just in case.

[asoderq]

I assume the internal memory is holding the bootloader. How would you go about to flash that? If the contents somehow gets corrupted, failed flashing etc, is it then bricked forever?

[TriForceX]

He's getting a splash screen so that suggests it's getting to u-boot at least. I suspect it's possible to unbrick it without replacing the chip like he mentions..

First thing I'll do is dump out the original firmware just in case.

i dont think a chip replacement is required, maybe just rewritting a backup into it (through uart) should be enough.

[fifteenhex]

Yes, that should be PM_UART. If you have an i2c dongle you can write the flash directly through it.
It's how I'll be backing mine up with they come

[fifteenhex]

Now on taobao: https://item.taobao.com/item.htm?spm=a230r.1.14.16.562176f3IemiWI&id=662148753424&ns=1&abbucket=5#detail

[fifteenhex]

I've started a wiki page for this here: http://linux-chenxing.org/infinity2/miyoomini/

[TriForceX]

I've started a wiki page for this here: http://linux-chenxing.org/infinity2/miyoomini/

Im preparing something similar here (i havent uploaded yet)
My plan is to add support to the console, similar to the work i did for first Miyoo consoles.

Im also preparing a package to update the SD contents (like proper configs for RetroArch) and the required build tools to ports APPS to Miyoo mini that the manufacturer sent to me.

[fifteenhex]

I guess they give you the old 4.x kernel to work with and the SDK binaries.
If we could get the sound working I think we could have everything you need working in our 5.16 kernel...
alas getting sound working is proving to be a massive pain.

[TriForceX]

I guess they give you the old 4.x kernel to work with and the SDK binaries. If we could get the sound working I think we could have everything you need working in our 5.16 kernel... alas getting sound working is proving to be a massive pain.

They refused to share any kernel / firmware source. I was able to get the SDK / toolchain only.

[asoderq]

Another review: https://www.youtube.com/watch?v=d7GXZ2wpA9U&ab_channel=TakiUdon

[fifteenhex]

Playstation games seem to work better than I expected. I haven't used a ps1 emulator in ages but all of the comments about the miyoo mini I read said it's probably only good for 2D ps1 games. Seems to be running some 3D games at a playable level.

[asoderq]

Jupp, the dynamic re-compiler helps a lot. Without it would run like crap. I think the whole library would run full speed if it clocks to 1.5GHz.

EDIT: Also, the GTE (Geometry Transformation Engine) is written with NEON instructions.

[fifteenhex]

I've had the SSD202D boosting to 1.8GHz (assuming we are measuring it correctly..). Not sure if it would run like that constantly.

Does the PS1 emulator actually make use of two cores.. like rendering the screen on one CPU and the rest of it on another?

[asoderq]

I am not that intimately familiar with PCSX-REARMED, but I don't think it benefits that much from multiple cores. PCSX4ALL, shares some heritage with PCSX-REARMED, is running fairly well on the single 1GHz Xburst core in the jz4770 and I believe it runs all games full speed on a single 1.5GHz Xburst core in the x1830. That is what I base my rationale on. Xburst should have slightly better DMIPS/MHz than A7 core, but I think PCSX REARMED with the NEON GTE is more optimized. Just my personal rough approximation.

[asoderq]

The display is apparently mounted 180 degree rotated. So the necessary 2d Graphics functions are rotation and hardware scaling.

[ddB0515]

got mine today from Ali so if anyone is interested I can dump SPI chip tomorrow and get more info (and maybe get boot log)

[TriForceX]

If you can send me the dump the SPI i would appreciate, im going to support Miyoo Mini too

[fifteenhex]

Getting some big high resolution photos of the back and front of the PCB would be really good. We can start tracing out the pins from the SoC. Output from booting and stuff like the output of /sys/kernel/debug/gpio would be good too.

[ddB0515]

Here is attached boot log
boot.log

Dumped SPI

flashrom v1.2 on Linux 5.11.0-43-generic (x86_64)
flashrom is free software, get the source code at https://flashrom.org

Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns).
Found Winbond flash chip "W25Q128.V" (16384 kB, SPI) on ch341a_spi.
Reading flash... done.

MiYoo283v1.1.zip

And log from /sys/kernel/debug/gpio

/ # cat /sys/kernel/debug/gpio                                                  
gpiochip0: GPIOs 0-90, gpio:                                                    
 gpio-1   (                    |GPIO Key Up         ) in  hi                    
 gpio-5   (                    |GPIO Key Right      ) in  hi                    
 gpio-6   (                    |GPIO Key B          ) in  hi                    
 gpio-7   (                    |GPIO Key Y          ) in  hi                    
 gpio-8   (                    |GPIO Key A          ) in  hi                    
 gpio-9   (                    |GPIO Key X          ) in  hi                    
 gpio-10  (                    |GPIO Key START      ) in  hi                    
 gpio-11  (                    |GPIO Key SELECT     ) in  hi                    
 gpio-12  (                    |GPIO Key MENU       ) in  hi                    
 gpio-13  (                    |GPIO Key L          ) in  hi                    
 gpio-14  (                    |GPIO Key L2         ) in  hi                    
 gpio-47  (                    |GPIO Key R2         ) in  hi                    
 gpio-59  (                    |sysfs               ) in  hi                    
 gpio-69  (                    |GPIO Key Down       ) in  hi                    
 gpio-70  (                    |GPIO Key Left       ) in  hi                    
 gpio-72  (                    |                    ) out lo                    
 gpio-86  (                    |GPIO Key POWER      ) in  lo                    
 gpio-90  (                    |GPIO Key R          ) in  hi                    
/ #

And Front and back images (as best I could take them)

[fifteenhex]

Do you mind if I stick these photos on the wiki?

[TriForceX]

thanks @ddB0515 ive uploaded your stuff in the miyoo mini section too https://github.com/TriForceX/MiyooCFW/wiki/Miyoo-Mini

[ddB0515]

Do you mind if I stick these photos on the wiki?

Ofc you can :)

[fkpwolf]

what's baud rate of UART? I have tried 9600, 115200...

[ddB0515]

I have used 115200 and worked for me, check RX-TX connections that was issue for me usually

[fifteenhex]

Finally got mine today.. working on getting mainline running now :)

[fifteenhex]

u-boot env

SigmaStar # printenv 
SdUpgradeImage=miyoo283_fw.img
baudrate=115200
bootargs=console=ttyS0,115200 root=/dev/mtdblock4 rootfstype=squashfs ro init=/linuxrc LX_MEM=0x7f00000 mma_heap=mma_heap_name0,miu=0,sz=0x1500000 mma_memblock_remove=1 highres=off mmap_r0
bootcmd=gpio output 85 1; bootlogo 0 0 0 0 0; gpio output 4 1; mw 1f001cc0 11; gpio out 8 0; sf probe 0;sf read 0x22000000 ${sf_kernel_start} ${sf_kernel_size}; gpio out 8 1; bootm 0x22000
bootdelay=0
cpu_part_start=14270000
dispout=K101_IM2BVL
ethact=sstar_emac
ethaddr=00:30:1b:ba:02:db
filesize=be44
miyoo_upgrade=gpio output 4 1; bootlogo 1 0 0 0 0;sdstar;
miyoo_version=202111201656
sdfw_version=202110071805
sf_kernel_size=200000
sf_kernel_start=60000
sf_part_size=20000
sf_part_start=270000
stderr=serial
stdin=serial
stdout=serial
usb_folder=images

Environment size: 913/4092 bytes

[asoderq]

Yet another review: https://www.youtube.com/watch?v=Kx5W1BNGVU4&ab_channel=RetroGameCorps
Main complaint seems to be a "hazy" screen, I wonder if that could be fixed...

[whmzsu]

The latest version had improved the screen similar to OGS tech.

[fifteenhex]

Looks like the battery changed too? The photos on aliexpress now have a battery with a cable.

[erazemk]

Looks like the battery changed too?

It has, it's now a 2000mAh one iirc.

[fifteenhex]

I bought two of the new ones. Will add some photos of the guts when they arrive.

[fifteenhex]

Screen seems to be the same.. but the new ones I bought do seem to be clearer than the original ones I got.
PCB differences are minimal. Just a connector for the new battery.

[fifteenhex]

Making good progress:

All of the buttons are mapped out but left and down don't register for some reason. Probably some pinctrl stuff.
SD card works. my hacky framebuffer works as long as the existing u-boot does the screen init: https://twitter.com/linux_chenxing/status/1479078829889290240

[ddB0515]

That's excellent news man 💪 well done
I hope for frame-buffer in 2022 :D

[samueldr]

Is there a complete list of GPIOs in use by the Miyoo Mini? I know about the GPIOs the kernel lists, and I know that 4 is PWM0 and used for the backlight. 48 is for the vibration motor.

Though I see 85, and 8 in use in the vendor boot command, and 12 in use in a vendor script. I haven't really dug too deep into finding out yet, but there's nothing obvious happening with either 85 and 8 in U-Boot (haven't tried 12).

[fifteenhex]

I think I have all of them in my kernel's DTS for the miyoo mini. There are two GPIOs that are used to sense if the charger is connected and to force the mosfet that connects the battery to the system on.

[qt-dork]

I just got into this after acquiring a Miyoo Mini Plus, and was wondering how things were going with on the kernel front over here.

Also, as an addendum to the screen flipping issue, apparently the Plus flips the screen to make it easier to reuse code? At least that's what I've heard.

[duckyb]

@fifteenhex in case it could be useful to someone, I took some pictures of my MiyooMini+ model.

[tGecko]

It would work, but it would come with problems. I did a RTC mod on mine:

https://github.com/anzz1/miyoomini-resources/wiki/Hardware-Mod:-RTC-on-the-Miyoo-Mini-Plus

EDIT oh wait, you're Kyek 😄

[SonicRay100]

What problems do you mean? Are you referring to not cutting the trace underneath or that the 3V button cell is not the required 3.3V for the RTC?

[duckyb]

Both

[tGecko]

This was a comment from before I decided to remove the SoC and cut the trace.
3V Lithium battery works just fine. If you don't cut the trace, half the system is powered on because it's on the same voltage rail as the RTC pin on the SoC, so you have a big power draw and the green LED is on all the time.

[SonicRay100]

Sweet thanks.

[JoNilsson]

Wondering what the progress is on this? It's been kinda quiet.
I've been browsing around this project looking for help with the Miyoo Mini +.
On my device I went looking in /config/modules/4.9.84 for an hid.ko and was bummed that there didn't look to be any such module.

I wanted to run vintage Amiga tracker (Protracker) on the Mini +

[fifteenhex]

For some reason I didn't get notifications for this issue.. @sebirdman is working on using our mainline stuff (i.e. Linux 6.5 etc) to make a firmware for the miyoo+.

[JoNilsson]

Awesome! My ability to contribute is limited to cheer leading. But fingers crossed for the mainline port to the miyoomini+. My primary interest in this is to run vintage Amiga, Atari and Commodore micro computer programs that require and human interface device, ie; hid.ko kernel module to allow interaction with a keyboard and mouse. Hopefully the hardware can support this via it's USB-C port. I'm using the stock kernel now, with Onion OS, and have found that many of the software for the aforementioned vintage computers work very well, so long as they don't require keyboard or mouse use. I'm following this closely with high hopes.

EDIT:
add info on the AXP223
Looking at the Board photos, it appears that the USB-C is connected to an SMT QFN Encapsulated AXP223.
Some more info on this IC:

The AXP223 is a PMIC (power management).
A PDF Datasheet marked "Confidential" can be found online.

Key features and functions of the AXP223 IC include:

1. Power Regulation: The AXP223 provides multiple DC-DC (switching) voltage regulators to efficiently generate various supply voltages needed by different components within a device. This helps optimize power consumption and extends battery life.

2. Battery Management: It includes battery charging and monitoring functions, allowing the device to safely charge lithium-ion or lithium-polymer batteries. It also provides mechanisms to prevent overcharging, overdischarging, and overcurrent conditions.

3. Voltage Monitoring: The IC monitors the voltage levels of various power rails to ensure stable operation and trigger appropriate actions if a voltage falls out of spec.

4. Current Monitoring: It can measure the current drawn by the device, helping to manage power usage and predict battery life.

5. Power Button Control: The AXP223 often includes a power button interface to control device power-on and power-off functions.

This caught my attn! ⤵

6. General I/O Functions: Some versions of the AXP223 provide additional general-purpose I/O (GPIO) pins that can be used for various purposes, such as controlling external components.

Gave me extra hope that a keyboard / mouse can be controlled via the mini+

8. Communication Interfaces: The IC typically supports I2C or similar communication interfaces, allowing a host microcontroller or system-on-chip to communicate with and configure the AXP223.

9. Low Power Modes: The AXP223 is designed to work in various power-saving modes, helping to minimize energy consumption during standby or low-power operation.

10. Thermal Protection: It incorporates thermal protection mechanisms to prevent overheating and potential damage to the IC.

11. Integrated Circuits: In some designs, the AXP223 might be used in combination with other ICs, such as microcontrollers, wireless communication modules, and display controllers, to create a complete solution for specific applications.

[sebirdman]

@JoNilsson

RE external usb devices

The data lines are not hooked up to the existing external USB-C port unfortunately. Two options exist:

1. Connect the ssd202 usb lines direclty to the USB-C external port (0.35mm pitch soldering here)
2. Get a USB Hub controller chip and unsolder the wifi chip from the other free usb port, then rewire it all properly

This is something I definitely want to investigate on my own once i've got the rest of the progress figured out.

RE general progress

We've got a lot of the actual hardware working. In fact - most of the hardware is functional. Here

Known outstanding hardware issues remaining are:

1. Power management - we can use the AXP223 chip, but actual real power management isn't complete. Known power management issues include: USB hub for wifi chip is always powered. Charging light does not turn on when charging. CPU is still setup on a fixed regulator - and it may actually be powered by the AXP223 directly.
2. Screen backlight is not yet working/tested

There's really three areas that need focus now. In order of priority for me:

1. We can't yet bring up the display on a custom uboot. Unfortunately - the stock uboot is very restrictive with how you can load a kernel and right now that means that the device takes a long time to boot up when using our custom kernel.
2. Fixup remaining hardware issues
3. The user land part of the device needs some work. Sadly, the current custom software's that run on the device heavily rely on the proprietary user land configuration of the stock kernel. Furthermore, after digging into these software's myself, i believe they are largely unnecessary and could be totally replaced with a nice retroarch theme and some small changes to allow better hardware control for the device.

As soon as i can actually figure out the whole uboot problem, and get a custom one with our own kernel running, i believe that we should be able to easily distribute an update for the end user for these devices that would allow an actual custom firmware.

[clort81]

RE external usb devices

The data lines are not hooked up to the existing external USB-C port unfortunately. Two options exist:

Am I correct in interpreting this to mean that the USB-C port is a charging-only port on the Miyoo Mini V4?

[free-gen]

Hello everyone. My MM+ has a very poorly calibrated screen. Green looks too overexposed, red looks a bit pink. The default image settings do not produce an acceptable result. I found a compromise solution in Koriki. There is a gamma adjustment (from cold to warm). But I do not like the Koriki interface, I prefer MinUI.
MinUI has hard-coded parameters for the default settings (lumon file):

params.stCsc.u32Luma = 45;
params.stCsc.u32Contrast = 50;
params.stCsc.u32Hue = 50;
params.stCsc.u32Saturation = 45;

I read the documentation for mi_disp, and found that there are also additional properties for display settings:

u16RedOffset
u16BlueOffset
u16GreenOffset
u16RedColor
u16GreenColor
u16BlueColor

Using the documentation, I came up with the following code sketch:

//Set Colors
	MI_DISP_ColorTemperature_t params;
	memset(&params,0,sizeof(MI_DISP_ColorTemperature_t));
	MI_DISP_DeviceGetColorTempeture(dev, &params);

	//00~FF, 0x80 is default
	params.u16RedOffset = 0x80; 
        params.u16GreenOffset = 0x80;
        params.u16BlueOffset = 0x80;
	params.u16RedColor = 0x80;
	params.u16GreenColor = 0x80;
	params.u16BlueColor = 0x80;
	
	MI_DISP_DeviceSetColorTempeture(dev,&params);

I am not very familiar with programming and project assembly, but before trying, I would like to ask those who understand these things - is it possible to add these properties to be able to calibrate my screen?

I already tried to build the original lumon file from MinUI repository, but I encountered the problem of missing header .h files (mi_disp.h & etc). Probably it is something from the Sigmastar SDK.
But it is not so important now. It is important to understand whether it is possible to add additional image settings at all.