There‘s only differentiation between newer and older eMMC versions
but the versions are backwards compatible, they have to be
but the versions are backwards compatible, they have to be
Yea this is right the protocol is the same but some reading/respond times are different.
Older Hwfly chips has Always problems whit hynix/Toshiba emmc's. It's a known issue.
Older Hwfly chips has Always problems whit hynix/Toshiba emmc's. It's a known issue.
That was a thing, yes. The oled switches with an skhynix emmc would boot to a black screen with the non flashable hwfly chip if an SD card wasn't present.
I.e. The "no sd card screen" will remain black.
The same modchip does display the screen correctly if the oled uses a Samsung emmc.
Post automatically merged:
This theory is actually plausible because the timings are anchored to the emmc chip. If chips from different manufacturers have ever so slightly different timings it could mean that the glitch is out of sync on some emmc chips.
Last edited by FruithatMods,
Someone install on mariko without hwfly cable and no remove resistor on cpu (no need to remove)?
The CPU has capacitors on it, the resistors mentioned are the three current-limiting resistors inline with the eMMC wiring.
You should just use a CPU flex. Install diagram on page 34. Really, you should just hold off on the install until the chip actually works, you're going to need to plug it back in to USB to install working firmware later. Unless you're going to be actively working on assisting development efforts, you're better off waiting until an actual modchip firmware exists.
The flex cable defeats the whole purpose of open source/ off the shelf components mod chip that would total 5-10 dollars total. And my purpose would only be using it for android / linux anyhow (delete if not allowed)
Fair enough, you will be able to use it for that right now, assuming the firmware works on your console. Until we nail down what consoles it does and doesn't work on, that's a gamble. About 50/50 it seems, but the sample size is tiny.
Yes, I get blue>white>green, screen remains black and console is actually in RCM (detected as Nvidia APX if connected to a PC) It hasn't harmed the console in any way, still boots stock just fine if the chip is disabled.
Have you tried powering up the Pico without it being hooked up to the switch at all? What LEDs start blinking?
Perhaps you should desolder it, power it up and then reconnect it to the switch again to try and see if it forces the Pico to write the new bct/Boot0 files.
So i try to install a HWFLY OLED in my lite with the same soldered wire from the rp2040 and it worked instant, so not a problem of installation like some people say
i desoldered it and put on the rp2040 again and the exact same issue has before
I also shorted the 2 pad for led on the backside, it behave the same i just got a green light instead of the yellow like before
I took some picture in Hekate before removing the hwfly, this switch has Samsung eMMC and DRAM
i desoldered it and put on the rp2040 again and the exact same issue has before
I also shorted the 2 pad for led on the backside, it behave the same i just got a green light instead of the yellow like before
I took some picture in Hekate before removing the hwfly, this switch has Samsung eMMC and DRAM
Attachments
You can even power it up using the switch itself as long as the other lines are disconnected.
Something like this:
Something like this:
Nope, all test points check out in normal ranges. I've checked for shorts across both CPU caps, shorts to ground and 3v3 on all chip points, checked all the eMMC lines for shorts to each other also. I've checked the resistance to ground of each individual line while disconnected from the chip to make sure they are making good contact with the pad, and checked under magnification to ensure they're on the correct pad and only the correct pad. I've tried 3 different RP2040-Zero boards on 2 different consoles. I've replaced the wires entirely and started fresh 4 separate times. I've tried all different lengths of CPU wire. I've tried with and without SD, formatted fat32 or exfat. I've wiped and reflashed each Pico at least 3 times, including trying it with the "locked" firmwares and then the "Ubuntu" firmware to see if those might do any init steps.
Interesting, looks like some of these chips have the other LED type, as mine is normally green at the end but becomes yellow with the pads jumped. Yours being the opposite. Seems unimportant though ultimately, but good we know that for sure.
When disconnected from all lines but power, the LED remains blue for about half a second, then light blue for another half a second, then nothing.
Here's a video of the behavior
Post automatically merged:
Removing CPU line = same behavior (blue > white > green > black screen)
removing rst = long blue light > green > Switch boots to stock
removing dat0, cmd, or clk = blue > white > green > black screen
Post automatically merged:
Removed the 47 ohm resistors, now always getting blue > light blue > black screen (with all lines connected)
Last edited by TheSynthax,
The other thing you could check is to boot the switch without the cpu line connected to see if it has a function to Rewrite the boot0 partition.
I think rewriting the firmware might be worthwhile instead of trying to reverse engineer this leaked firmware.
I think rewriting the firmware might be worthwhile instead of trying to reverse engineer this leaked firmware.
With or without the CPU line, behavior is the same. Ditto on rewriting the firmware.
Similar threads
- No one is chatting at the moment.
-
@
K3Nv2:
If Jack didn't think about pussy he could've made some friends with a good few millionaires tbh+2 -
-
-
-
-
-
-
-
-
@
Xdqwerty:
@SylverReZ, ok sorry. Btw im worried, there is a spelling bee tommorrow and i barely practiced at all -
-
-
-
-
-
-
@
K3Nv2:
One of my friends wants to do a pc wall build I'm like but you constantly complain about roaches lol
-
-
-
-
-
-
-
-
