Just came back home and did a quick boot0/1 rebuild and flash test on Mariko.
boot0/1 gens from donor_product.key indeed boots my Mariko up fine. Kind of confirmed boot0/1 somewhat interchangeable from different product.keys gen but has to be same OFW(i.e 16.0.3)
2 Likes
donor key is found from stheix level3 YT videos UNBRICKING THE NSW LEVEL 3 : DO NOT FOLLOW THIS GUIDE BEFORE BACKING UP THE NAND - YouTube
I did boot0/1 flash from hekate emmc mount, and flash the emmchaccgen boot0/1 bin files(1.5MB) via balenaEtcher v1.5.24. (Iām on win10 PC)
EmmcHaccgen GUI has 2 version from stheix or suchmememanyskill Should both works same.
2 Likes
Perfect, thanks bud!
And just to be clear, NxNandMamager_5.2 does not support FW ver shown after OFW 13+ I believe, so donāt pay too much attention to the unknown from the top bar
1 Like
Wow, this gives me some hope!
I am going to check the video and try to replicate it.
Is there a way to identify the firmware? Or, in case, I will start from the newest one and going back.
I assume that if the case is in the boot partitions, the regenerated boot0/boot1 will work just when I match the firmware on the Switch, right?
For clarity: would this procedure provide a clean boot, so able to boot OFW without chip?
Another question: do I risk to burn the fuses somehow, trying with different firmwares?
Thanks again!
hekate tells you the firmware om your device.
itās not gonna burn fuse and why would that matter?
He canāt use Hekate due to the dodgy modchip (or suspected bad modchip/install)
Hi @jkyoho
I saw the video you linked but even here the precondition is to have prod keys, which I donāt have. As @Severance mentioned, I donāt have access via the modchip either.
Before desoldering it, my HwFly Rp2040 gave me the following error (with led blinking): *== No eMMC CMD1 request (poor wiring, or dead CPU). Thatās why we checked for the emmc with the mmcblkNX tool.
There was a time, before closing the console, when the modchip was booting.
But at that time, I had no possibility to boot to Hereke and dump my partitions/keys.
The last time the modchip was connected, this was my issue:
streamablecom/dx0vku
What I donāt get is why the modchip is not able to boot again to that screen, even if the Boot0 is messed up 
I hope something is still possible, thanks!
The yt video has the donor product.key in the description section for download.
For you *== error code, you need to provide details picture for all soldering point you worked on
nvm, I saw your pictures from the other site
what picofly fw did you use in your mod chip? try flash it to v2.73 and see if you have ** blinks after flash and reconnect to PC(NO switch button push)
The first time I directly used the firmware with which it was shipped, as the seller stated that it was not necessary to update it.
After the black screen problem, I updated it to 2.73 but no changes in behavior. Yes, connecting it to the pc the chip gives me 2 ** blinks.
I can ask the seller for the firmware version, maybe it can be useful to find out what kind of writing the modchip did on the boot and if it had bugs (I only heard about this after installation).
Note: I am going also to try generating clean Boot 0 and Boot 1 as you mentioned. I hope I can make it work at least as stock with OFW.
Work your way up the FW versions (for boot0/1) instead of down, maybe start 3/4 versions down (or more if you donāmind spending the time) from the newest version. As far as I remember, primary version numbers will work iregardless of the decimal place - so in theory V15.0 should work fine on V15.4 (just a random example) and vice versa ā¦ atleast it used to work fine lke this back in te day so its better to work your way up instead of down (as your fuse concerns are valid)
btw have you confirmed your primary rails resistance to ground yet? bit pointless doing al this if you find you have a soft short on you 3v3pdr (for example) etc
Also, Iām just gonna write this now before I forget (and potentially as a warning) Not relevant to your current situation @minimanimo but might be later on if you ultimately can boot again stock. Iām reading over your gbatemp post here
And noting the guy saying the chip has āproblems with toshiba IC EMMCā This is an odd thing and doesnāt make much sense, but then I thought about it, the RP IC I/O likely operates at a 3.3V logic level, so if there is no level shifting circuitry on this modchip āPCBā then itās entirely likely itās using 3.3V logic on VCCQ (normally 1.8V) and the same goes for the other I/O/rails on Switch - I mean maybe there is circuitry (if somone can confirm) or maybe you can independantly set the logic level of specific I/O on RP (if someone can confirm) but if not, it really is no wonder these modchips (and that would be all variants) are corrupting EMMCās and/or damaging SoCās etc
Maybe someone can confirm this for me by measuring the voltage on EMMC lines on the modchip (VCCQ, CLK, Dat0 etc)
That wont be the concern IMO. From both source code and actual Voltage measurement from DAT0, CLK,CMD, 1.8v is measured from those data line on picofly/rp2040. Also from my understanding Vccq and rest emmc pinout is just pass-through or not even been used for this kind of mod.
FYI, I am more tend to believe the *== error @minimanimo got is due to the poor soldering/code joint on the CPU cap(from what I saw from pictures) other than FW bug or anything.
Itās not passive, itās active during the āglitching processā, so the SoC is always modifying (stock) the EMMC at boot, read/write (boot0 is modified at every boot by the SoCā¦ maybe a boot counter I donāt know), so the glitching by the modchip is effectively interfering with this, think of it as a fight (at least as far as I understand it, I would not be surprised to see read/write commonds to the EMMC even while glitching is in progress using a scope) - following glitching the modchip modifies the EMMC data on boot 0. Now depending on how the modchip works, it might only modify boot0 one time (or following every update where the boot0 is returned clean/stock) - So yeah, might be passive following initial modification.So your measurments might not be accurate (if it only modifies boot0 once) 
Yeah agree, but I do think he now has EMMC issues and/or hardware issues as a result. Best to confirm this prior to worrying about the modchip
1 Like
very ture, I remember early day when picofly has older fw, there was black screen/blue screen boot up issue(can be found from FW changelog). The way to fix it was OFW update through WiFi which means that was boot0/1 curpttion when initial sdlodaer injection. Later FW like v2.54 or something rewire the injection sequence and FW tends to less critical bug from that point.
1 Like
Yeah. My concern is, even though this particular EMMC IC can most definately tolerate 3.3V on itās IO, the rest of the board canāt, and while Iām not all that familiar with the EMMC protocol, Iād wager at power on it evaluates what logic level itās operating at to avoid errors (data will be interpreted differenlty at different LL) - so the concern is it basically trying to operate at two different LL at the same time while Read/write commands are going onā¦ recipe for disaster, but if it only does it onceā¦ probably gets away with it most of the time
Hi @Severence and @jkyoho,
Iāve tried to build a Boot0 and Boot1 with generic prod keys (found by googling) using 16.0.2 firmware but no luck.
I didnāt try for any lower firmware, as I didnāt find the related keys. Honestly, neither ādonor keyā in level3 YT videos, just the donor nand. So, I cannot exclude the generate partitions were just not perfect.
Note: Iāve compared the with the Hex editor the generated Boot0 with the ācleanā one in post #25 and from Offset 00000000 to 00000100 looked the same. Different from 00000220.
I believe my switch have 16.0.x, as we usually connect it to internet and sometimes played online. You said a boot for 16.0.2 should work also if the switch has firmware in range of 16.0.x, right?
If yes, would it possible for you to share your Boot0 and Boot1 clean partition with me? As they are generated already, no prod keys can derived from them. I would try to write them and run the console.
Another question: assuming the console is a good state and is just matter of modchip flex issue/connection problem. If I get an original HwFly modchip, would it be able to overwrite the junk written by the Picofly and boot the console?
Thanks again in advance folks!
