Nothing, really. I put the mosfet on the back on OLEDs because I find it easier and I don't have to lift the apu cover at all. front mosfet on v1/v2/lite since then I can skip detaching the mainboard. I use the green reball adapters for emmc on OLEDs because it's a more permanent solution (than the slide-under dat0 adapters) that also provides easier CMD/CLK points, and allows me to not have to cut any shield frames.
The resistor thing isn't just "pass" or "fail" either - some switches don't get the slow emmc error, but are still somewhat unstable in ofw. One v1 I had sometimes crashed on wakeup after being in sleep mode for a long time, for example. I figured it would be nicer to have a setup that works for every switch without having to spend time double checking that everything is stable. I started using 100/100/47 for everything just to test and I have had zero resistor-related issues since. It confuses me why some people stubbornly refuse to change the default recommendations when 100/100/47 always works and has no drawbacks. It would spare us from having to answer the same question over and over. After all, the old 47/47/47 was simply something rehius happened to have lying around and it happened to work for him at the time - there is no science other than trial-and-error behind these recommendations.
Post automatically merged:
Thank you for the kind words
Post automatically merged:
Do you have a picture? How do you fit that many resistors?I have two Erista's with some weird error, one has a EMMC slow error, and the other, Atmosphere just errors out, or doesn't boot. Booting to OFW seems to work fine on both.
EDIT: Also, wouldn't a 240ohm resistor do the same as 100/100/47?
Attachments
Last edited by deeps,
I see, thank you for your insight! Altohugh i know how to reball, i thought the adapter method was preferred. cuz i heard that if you try to reball, the solder balls could crack and could cause the and not to work, is that just not true?
Also could i see what you mean with the mosfets on the back and on the front? Also, what do you mean that you don't have to lift the apu cover at all, how else do you access the apu?
Anyways, thank you!
eri tommino81 su consoleopen???
Post automatically merged:
same version 2.75
Another problem with RP2040 on Mariko I had after 4 months. The customer complained about original boot with error on Picofly**. I thought it was a false contact on RST, when it came to me the values were normal on RST. On the other hand, the 3v3 line had a very low value of 1000 to 229 in diode test mode. replaced the picofly I fixed. This one I tried on another console but it had the same flaw, I trashed it and amen.
Last edited by LuigiGad,
The cracking happens when you put some solder on your dat0 adapter, insert it, and then heat the emmc to get the dat0 ball to fuse with the contact point on the dat0 adapter. What really happens is you are forming an imperfect bond between different solder alloys that will expand/compress differently with temperature variations, which may crack over time. With a full reball you are replacing all the solder with the same type (preferably leaded, or a bismuth-silver based variant with equivalent ~180c melting point), resulting in strong solder balls and no cracking worries.
"mosfet on the back" - alternative mosfet solder points on the back side of the motherboard. see picture. no need to lift apu cover because you don't need to solder anything to the apu if you put mosfet on the back of the board.
"mosfet on the front" - mosfet mounted on the apu, same place as the hwfly flex cables. see other picture.
Attachments
If you are asking if i'm tommino81 in another forum the answer is no
There are some issues that were seen with rp2040 (depending on the clone)
One that rehius mentioned was that the 3v3 LDO fails sometimes and renders rp2040 useless so he suggested that we remove it.
The other one that I encountered was a failed crystal (after 1-2 months) and it gives clk error code.
Beware, it is a more difficult job and it takes more time to install. I only do it because I think it's the best way and making money from modchip installs isn't my first priority.
By adding another resistor (3x 47 ohm) fixed my issue. In another thread, I read someone had to use 4 but I tried with 3 and it worked.
Actually have a hwfly chip that I was going to try but luckily wasn’t needed. Would have been interesting as a test but I didn’t want to disassemble the switch again.
Just want to add that the 'slow emmc' might be related to lower version of the firmware.
The explanation is like this:
The rp2040 ideally only works at boot until it goes to hekate, then shutdown.
But rp2040 cannot be programatically shutdown, so its still have somekind of interference with the line.
The dat0, cmd, clk is not at high impedance, when the glitch finish.
So everytime the glitch is done, the firmware try to 'shutdown' the rp2040 programatically.
On previous version, theres bug on the 'shutdown' mechanism, that is why the rp2040 not properly turn off, and interfere the emmc, resulting the various issue on emmc.
In conclusion, make sure to use the latest picofly firmware.
If you could modify your rp2040, so it could turn off mechanically / electronically, after the glitch done, it would be another solution.
The explanation is like this:
The rp2040 ideally only works at boot until it goes to hekate, then shutdown.
But rp2040 cannot be programatically shutdown, so its still have somekind of interference with the line.
The dat0, cmd, clk is not at high impedance, when the glitch finish.
So everytime the glitch is done, the firmware try to 'shutdown' the rp2040 programatically.
On previous version, theres bug on the 'shutdown' mechanism, that is why the rp2040 not properly turn off, and interfere the emmc, resulting the various issue on emmc.
In conclusion, make sure to use the latest picofly firmware.
If you could modify your rp2040, so it could turn off mechanically / electronically, after the glitch done, it would be another solution.
I prefer 2.76.
2.75 already fixed the 'shutdown' issue though.
This is what i understand about the changelog of 2.76:
* Finer timing step for searching glitch point from 10 -> 8.
* Change algorithm of waiting for glitched identification on dat0.
* Change of the timing parameter when uploading data to the emmc via dat0.
(Its pretty drastic from 4248 to 527. I've no idea what is the impact. But i think it is modified by trial and error.)
So, I decided to turn on my switch to OFW and got error code 2002-3539. Saw it was a problem with the NAND, but eMMC partitions was still there and it does pass through the Nintendo Logo and the Switch Logo before hitting the error. Checked my RP2040 Flyboard-clone firmware version and saw there was a new version. So I booted up the picofly toolbox and updated. No idea if it worked because after a reboot my switch went straight to purple screen and checking eMMC info says the entire GPP partition got wiped.
Currently restoring with a fresh backup of last week. But it is annoying to see this happening. Just hoping the NAND chip isn't fried.
edit: Restoration done. Now I'm booting into a black screen... this is just sad. Oh, and Picofly_toolbox reports it as still the same version so it didn't update. And updating it does clear the eMMC... again. Back to another half hour of restoring.
Currently restoring with a fresh backup of last week. But it is annoying to see this happening. Just hoping the NAND chip isn't fried.
edit: Restoration done. Now I'm booting into a black screen... this is just sad. Oh, and Picofly_toolbox reports it as still the same version so it didn't update. And updating it does clear the eMMC... again. Back to another half hour of restoring.
Last edited by Ravenext,
By clone do you mean the classic one or those that come with flexes?
If its the latter that's your answer, there's too much interference happening leading to your data corrupting. When I used my own flex I designed same thing happened, my partition table got wiped, restored and it got wiped again until I lifted the flex and used wired instead.
If you using custom board, you need to make sure its compatible with the firmware in here.
That purple screen usually about cmd resistor on the mainboard.
The one that comes with the Flex Cable. As for the installation. I followed Sthetix's YT guide and went do with enameled copper wires because the Flex did prevented me from booting to OFW the first time I did the install. I'm going to have to bring this to the workbench to see if the soldering got bunched up and if needs be, fix them.
Well, restoring the backup did remove the purple screen. But now its replaced with a black screen. As for checking to see if its compatible with the update... tbh I thought Rehius' firmware would just work with the clone boards running Ansem's
edit: re-soldering the wires did not do anything.
Last edited by Ravenext,
anyone familiar with the following issue? I have a picoflyed switch lite, wich sinds last week randomly the screen freezes and becomes unresponsive, only solution is holding the power button until it reboots in hekate.
So, there was a reddit post by someone who also got the same problem and they got told to retrain the pico. Well, it does work and no longer black screens after the Nintendo Logo. But....
Sadly, I just return to the same error code that started all of this mess.
Sadly, I just return to the same error code that started all of this mess.
Well it boots into rcm mode, so that's good. Just delete your atmosphere folder and reinstall it from fresh and make sure your fusee.bin is updated. With the latest from the githb page.
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
-
-
-
-
-
-
-
-
