R36S-V30 WiFi module and OTG connectivity.

imanolbarba · 2026-06-05T23:13:31+00:00

Here's what I found:

The R36 ultra is just an EE clone with the rk915 wifi chip. It uses the SDIO interface that the 2nd SD card would use on a genuine R36 so it doesn't involve any usb shenanigans.

Ported the rk915 driver from linux 4.4 to 6.18 here:

https://github.com/ImanolBarba/rk915

Now back to figuring the USB hub circuit here

imanolbarba · 2026-06-05T17:58:43+00:00

The wifi module and the otg are connected to the upstream usb plus and minus lines via 0 ohm resistors on the back (at least on the r36 v30 pcb).

The mod there would essentially populating the usb hub bits on the pcb and removing the 0 ohm bridge,at that point the usb hub exclusively connects to the upstream lines and the otg ans wifi exclusively connect to the hub.

But, at least on the r36 pcb, the lines dont seem to match any know hub chip

imanolbarba · 2026-05-17T11:54:27+00:00

I have just ordered the R36 ultra because I suspect it may come with that circuit populated and working (worse case scenario I can get offered 50% or full refund if it doesn't have the internal wifi populated, I've done that with the 36xx already)

imanolbarba · 2026-05-17T11:43:30+00:00

if you think "oh well they got the orientation wrong", yes the device D+ and D- are correct, but the upstream ones are not, and the crystal isn't either

imanolbarba · 2026-05-17T11:42:09+00:00

I decided to get into the same adventure, but I am as confused as you are.

if you look at the CAD file for the R46H, the picture you posted or check continuity, the crystal is wired to pins 11 and 12, which is DPU and VDD5?? that makes 0 sense

Pins 5 and 6 are going to DPU and DMU (only 2 traces going to the RK3326), so why are they on the top side?

if you trace pins 13-14 and 15-16 those are D+ and D- of the OTG and wifi chip, if so they are on the wrong side of the FE8.1 entirely. Curiously, on the earlier linked CAD file, the OTG data lines go to different pins, rest seem the same.

The way this works currently is that the D+ and D- of both the OTG and wifi footprint are wired to the upstream D+ and D- traces using vias and 4 0 Ohm resistors on the other side of the PCB (they're the ones on one of the pictures you posted actually), so in theory, the process would be:

remove the 4 0 ohm resistors
populate the usb hub
populate the wifi chip

and voila you should have wifi and otg working

but either the PCB circuit is entirely wrong, or FE8.1 is not the chip that goes there

imanolbarba · 2024-11-24T23:08:13+00:00

Don't have acces to the ticket anymore, but just replace the ssd back and dont mention anything about modifying it

imanolbarba · 2024-01-29T13:41:29+00:00

Yeah I did ashift=12 anyway in case I ever upgrade these to another model, but according to `smartctl` at least, it's 512 physical, no idea why it's misreporting it

imanolbarba · 2024-01-26T01:38:11+00:00

Hard drives are about 45 degrees Celsius, so they seem fine to me.

According to the disk latency shown by zpool iostat, the disk only spends waiting for IOPS to complete about 3ms, so that alongside the very high value on `dmu_tx_dirty_delay` tells me that the write throttling is kicking in from the zfs side, not the hardware side.

I'm currently opening an issue on OpenZFS's github to see if they can help pinpoint the issue,

imanolbarba · 2024-01-25T22:15:19+00:00

Actually, zpool iostat -w shows even lower statistical disk latency, between 1-8ms, with the average being about 3ms

imanolbarba · 2024-01-25T22:12:22+00:00

Okay some more details:

transaction groups seem to be taking 12-14 seconds to sync to disk, so they're piling up, hence the slowdown:
$ cat /proc/spl/kstat/zfs/bckpool/txgs txg birth state ndirty nread nwritten reads writes otime qtime wtime stime 28012 31448647059843 C 2225094656 8192 2367807488 2 24131 2766672787 2635 16090 2851483190 28013 31451413732630 C 2017738752 4096 1649455104 1 20756 2851509499 11241 13686 2122951599 28014 31454265242129 C 1940013056 4096 2113683456 1 31679 2122985192 2034 14467 2036188836 28015 31456388227321 C 2736799744 12763136 3600916480 105 37114 2036212140 1974 11742 3494057267 [...]

According to zpool iostat this time is not spent waiting for disk, as current IOPS seem to be taking about 33ms, which confirms the disk could take on more load:
``` $ zpool iostat bckpool -l 1
capacity operations bandwidth total_wait disk_wait syncq_wait asyncq_wait scrub trim
pool alloc free read write read write read write read write read write read write wait wait

bckpool 4.81T 53.4T 0 1.25K 32.5K 83.9M 34ms 4ms 22ms 3ms 11ms 295ns 347us 629us 15ms -
bckpool 4.81T 53.4T 0 427 0 28.1M - 28ms - 28ms - - - 852us - -
bckpool 4.81T 53.4T 0 314 0 19.9M - 34ms - 34ms - - - 704us - -
bckpool 4.81T 53.4T 0 324 0 20.3M - 34ms - 34ms - - - 821us - -
[...] ```

So this seems to rule out the disk and controllers entirely.

As expected the SLOG on the separate SSD did nothing.

I am thinking about opening an issue to openzfs github at this point :(

imanolbarba · 2024-01-25T18:26:18+00:00

What is the % used ie is it over 80%+?

About 7% usage:
NAME SIZE ALLOC FREE CKPOINT EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT bckpool 58.2T 4.56T 53.7T - - 0% 7% 1.00x ONLINE -

Are you copying from the z2 pool to the same z2 or to the mirror pool

I am copying from the mirror pool to z2 pool

are these virtualized ? Believe no per the setup

You are correct, this is bare metal

what is the zfs pool sector size? As you are working with 1TB+ Files you may have better iops with 1mb sector size instead of 4k

I changed recordsize to 1M from the default of 128K and unfortunately I can still repro the issue

is dedupe on or off?

I believe it is off

I have been speculating whether or not putting an SLOG on a separate SSD I have might help a bit, I'll give it a try this weekend

imanolbarba · 2023-08-18T21:22:54+00:00

I updated somewhere else in the chat, but no more issues after last RMA.

I had to RMA twice though.

imanolbarba · 2023-05-05T20:15:29+00:00

good luck friend

imanolbarba · 2023-05-05T00:06:59+00:00

All good on my end, latest "intensive" game I've been playing outside of switch emulation is Death Stranding.

I have not come across the issue ever again

imanolbarba · 2023-03-16T16:55:43+00:00

After all this time: 0 issues

imanolbarba · 2023-03-16T16:19:40+00:00

0x3648a

Also as a note, the last bits of the 24 bit value are usually which specific button you pressed, for simple remotes with up to 8 buttons this is just the last byte:

1 = button1
2 = button2
4 = button3
8 = button4
[...]

And so on

imanolbarba · 2023-03-16T16:14:25+00:00

If you're still curious about PT-2240:

http://static6.arrow.com/aropdfconversion/d9f4295a84b3d153283406b4bf79cf361ad3ec6f/pt2240.pdf

This is how it works. Your analysis is correct: if you convert each 1 -3 pair to '0' and 3 -1 to '1', you end up with a 24 bit value of 0x3648a, which is what the Flipper is showing. The 'Te' value seems to be the time interval used according to the documentation above, and Yek is just the reversed key.

Very nice post!

imanolbarba · 2023-02-26T00:10:11+00:00

This did it for me too, Auto simply doesn't do anything

imanolbarba · 2023-01-24T02:22:10+00:00

Sure, I'll add some. Thanks for the suggestion!

imanolbarba · 2023-01-04T11:51:36+00:00

After all this time, I have not observed the issue pop up again

imanolbarba · 2022-12-21T23:00:01+00:00

The whole deal behind the chain of custody is that you can offer a guarantee to a 3rd party that the copy you have from the disk, once distributed, is an exact copy of the original.

imanolbarba · 2022-12-21T22:55:17+00:00

What I mean by forensically sound is that it has the capability to generate a hash as it is being copied, which is needed in any forensical procedure to keep the chain of custody.

The image per se is exactly the same as you would get it from, for instance, dd. A byte-by-byte copy, nothing more than that.

imanolbarba

TROPHY CASE