Dingoonity.org

Interesting that the devices are so similar in hardware.

The problem with the keys is probably due to them being connected to different pins. To figure out which button is connected where, enable debugfs in the kernel, so you can get logging of the current state of each pin via text files in "/sys", then hold a button and see which pin flips.

To build your own kernel, you need a Linux system, but you can use a VM or even Docker in Win10 if you don't have a native Linux install. Install the RS-90 OpenDingux toolchain from Paul's blog post. Add the toolchain's "bin" directory to your $PATH.

Then issue the following commands:

git clone https://github.com/OpenDingux/linux.git
cd linux
git checkout jz-5.1-retromini
make ARCH=mips rs90_defconfig
make ARCH=mips uzImage.bin -j4

Use a different "-j<N>" depending on the system you're building on; something near the number of cores you have is typically good.

The "devicetree.dtb" is created as part of the Linux kernel build. The sources it is built from are in "arch/mips/boot/dts/ingenic/".

To enable debugfs or other kernel options, use "make ARCH=mips menuconfig" after applying the defconfig and before building the "uzImage.bin".

I don't have time right now to do a detailed guide, but I hope this helps you get started.

You'll have to recompile the linux kernel and modify the dts file according to what the GPIO pins are mapped to.
See here :
https://github.com/OpenDingux/linux/commit/46db086c644ca6f00e422f727d57bd30712d8a74

As for the /sys thing, i think he means /sys/kernel/debug/pinctrl/.
You may have to export the other pins via /sys/class/gpio.

Btw, i can't find that device anywhere, it's out of stock now. What a shame

pretty amazing raziel gave it a go and it nearly worked. i have one of these laying around, maybe if it gets fixed i will try it myself.

i realize this device is not a priority, but if the controls ever get fixed i'm gonna try it on my own. i found it and dug it out.

The problem with the keys is probably due to them being connected to different pins. To figure out which button is connected where, enable debugfs in the kernel, so you can get logging of the current state of each pin via text files in "/sys", then hold a button and see which pin flips.

You need a little more than this; the kernel will only display in debugfs the state of the GPIOs that have been requested. So you would need to request them and test them one by one.

Use toolchain for rs-90.

Отправлено с моего LLD-L31 через Tapatalk

Alternatively, if you're in Europe, send it to me and I'll do it for you (then send it back).

Hello everyone,
After a very long time, I'm back to this topic.
During covid19's lockdown I had some spare time and I tried to make the PMP-V work again.
I still can't figure out what to do with debugfs, but I could compile uzImage.bin and I spent some time tinkering with the rs90.dts file.
At first, I tried different combination of gpio values for up and down keys. Everytime, I made a new uzImage.bin, flashed the device and tried if I got something, but to no avail.
Then, I figured that since the down key acted as the L key, I looked into the portion of the dts file which takes care of left shoulder button.
I now have a responsive down key with this code:

[email protected] {
compatible = "adc-keys";
io-channels = <&adc INGENIC_ADC_AUX>;
io-channel-names = "buttons";
keyup-threshold-microvolt = <1400000>;
poll-interval = <30>;

[email protected] {
label = "Select button";
linux,code = <KEY_ESC>;
press-threshold-microvolt = <1100000>;
};

[email protected] {
label = "Left shoulder button";
linux,code = <KEY_TAB>;
press-threshold-microvolt = <900000>;
};

[email protected] {
label = "D-pad down";
linux,code = <KEY_DOWN>;
press-threshold-microvolt = <100000>;
};
};


As I understand, the 3 keys are linked to an adc pin which measure different voltage when those keys are pressed.
It sometimes is buggy: the down key sometimes activates L or select keys, but I could play some games where up key is not too important.

After that, I tried other values to see if I could get a response from the up key.
I got something with this:
[email protected] {
label = "D-pad up";
linux,code = <KEY_UP>;
press-threshold-microvolt = <2900000>;
};
In fact, the up key seems not to respond at first. But when I press down, select or L, the device thinks the up key is always pressed after that. Then, if I push the nub up (yes, it's an analog nug and not a digital dpad), it acts like the up key is not pressed anymore.
Also, this react like this if keyup threshold value is lower than the up key press-threshold value.
I think that when the nub is centered, the voltage is around 1.5V. Pushing down lowers the voltage and pushing up makes it bigger (I didn't measure anything, it's just my guess)
The problem is that press-threshold-microvolt only detects a voltage going under the press threshold and I need to detect when it goes higher than that.

I tried inserting a dummy key between up and the rest (when the nub is centered, it should react to this dummy key and nothing should happen):
[email protected] {
label = "Dummy";
linux,code = <KEY_J>;
press-threshold-microvolt = <2500000>;
};
But it doesn't change anything even if I use a keyup threshold higher than the press threshold of the up key (as before, in that case, the always up phenomenon doesn't occur).

I will give a try with a part of pcerceui's gcw0 code:
joystick {
compatible = "adc-joystick";
io-channels = <&adc INGENIC_ADC_TOUCH_XP>,
      <&adc INGENIC_ADC_TOUCH_YP>;

[email protected] {
linux,abs-code = <ABS_X>;
linux,abs-range = <3300 0>;
linux,abs-fuzz = <4>;
linux,abs-flat = <200>;
};
[email protected] {
linux,abs-code = <ABS_Y>;
linux,abs-range = <0 3300>;
linux,abs-fuzz = <4>;
linux,abs-flat = <200>;
};
};
This code seems more logical to manage an analog nub, but I'm not sure the RS90 is made to react to this.

Has anyone got any idea?
The left and right keys reacts to gpios, could they also be linked to and adc? Likewise, could up and down keys be linked to standard gpios (As of now, I tried gpc 0 to 31 and gpb 24 to 31)?

I'm from France and it's difficult to explain all the technical stuff in english, but i think some devs here speak french.


Thanks to those who already tried to help and to those who will.

Take care.

Well, Paul, you're the man!
Merci, merci, merci, merci, merci, merci, merci, merci, merci, merci, merci, merci, merci, merci, merci, merci, merci!!!!!!



I was mistaken about the press threshold. It doesn't trigger if the voltage goes under it, but above. And the voltages from up and down keys don't depend on how far I push the nub.

The rules for attachment files won't allow me to post the uzImage.bin I generated for those of you who don't know how to compile it themselves (it took me a little while to get the hang of it!), but here is the code:

[email protected] {
compatible = "adc-keys";
io-channels = <&adc INGENIC_ADC_AUX>;
io-channel-names = "buttons";
keyup-threshold-microvolt = <3300000>; // No key pressed voltage: 3754
// (from: cat "/sys/devices/platform/10070000.adc/iio:device0/in_voltage0_aux_raw")
poll-interval = <30>;

[email protected] {
label = "D-pad up";
linux,code = <KEY_UP>;
press-threshold-microvolt = <1400000>; // Up key pressed voltage: 1700
};

[email protected] {
label = "Select button";
linux,code = <KEY_ESC>;
press-threshold-microvolt = <1200000>; // Select key pressed voltage: 1316
};

[email protected] {
label = "Left shoulder button";
linux,code = <KEY_TAB>;
press-threshold-microvolt = <700000>; // L key pressed voltage: 848
};

key[member=31360]3[/member] {
label = "D-pad down";
linux,code = <KEY_DOWN>;
press-threshold-microvolt = <100000>; // Down key pressed voltage: 212
};
};

It might require some tweaking, as the select and L keys sometimes get triggered by up or down key and vice-versa, but I spent a few minutes testing some games and all was good. It's just when I launch the terminal that I see this weird behavior (and sometimes while browsing files, a press on down generates a press on L which makes me go back up 4 lines in the list).

Attached to this post is a couple of photos to help you identify the device (the image I linked to in my initial post seems to be gone).
I used Paul's opendingux-flasher-2020.01.06 with flash_v21.
The device is much much enjoyable with opendingux than with the original firmware: multiple savestates for one game, much more options and emulators and better graphics (snes looks very good with Snes9x4D).
But remember: you flash your device at your own risks. I won't be held responsible if anything goes bad and your device or your computer gets bricked.
I hope this can help some of you.




Anyway, a big thanks to Paul. I feel like it's christmas morning!
I won't investigate about other gpios for up, down, select and L keys unless I can get a better way to investigate it. Paul's last tip was really helpful. I can't carry on trying to test each possibility: each try cost 4 minutes and I can only try one gpio at a time. Moreover, I don't think the nub acts like an analog device.

I still have a question:
with an opk update, does uzImage.bin gets rewritten? This would mean I would have to update with a full firmware flash with every update. Judging by the opk's size, I guess it's just rootfs.squashfs that gets rewritten, but I could be wrong.

Take care everyone.

If you can send me the .dts file, I can support the PMP-V officially in the next update.
Did you find where the X and Y buttons are connected?

About in_voltage0_aux_raw: I forgot to say that, you have to multiply the value with the scale (3300/4096) to get the actual mV value. So if you read 1700 for the Up key, the measured mV value is 1700 * 3300 / 4096 = ~1369 mV.

The annoying thing about having buttons connected to the ADC, is that these buttons cannot be pressed at the same time. I have no idea why they went with such a stupid design, especially since there still are free GPIOs...

You can support this device too??


https://a.aliexpress.com/_dVrBkgm

Enviado de meu moto g(7) play usando o Tapatalk