Hacking Question Memloader freezing

  • Thread starter Thread starter K1ck09
  • Start date Start date
  • Views Views 10,430
  • Replies Replies 22

K1ck09

Active Member
Newcomer
Joined
Jan 29, 2019
Messages
25
Reaction score
1
Trophies
0
Age
27
XP
239
Country
Portugal
Hello,

A strange thing is happening with my switch. Hekate and biskeydump payload work just fine but when I try to use the memloader, the switch just freezes...
I dumped rawnand and boot0/1 using hekate, all worked fine. Restored boot0/1 with hekate, all fine.
I'm using a NEW 128gb sd card and I tested with FAT32 and exFAT, no difference(I copied all necessary files to the sd card!).
I inject the payload, everything is fine, I select one *.ini and the console just freezes here:
cd3Tslkl.jpg

If I select USB Mode it stays like this(the try count keeps going up):
BgfhdJWl.jpg


Best Regards.
 
Well for some reason the connection is either not working or is being actively refused by the devices. Not sure what to tell you. Sorry

--------------------- MERGED ---------------------------

Maybe try using TegraRCMGui and launching the sd tool that way? Technically uses the same tool but might help you figure out if the driver is the issue or something
 
yea i had same issue a couple times
try unplugging the Cable then get to the menu selection where you select the emmc.ini
plug the cable in now then hit power to start it that worked for me might work for you
 
  • Like
Reactions: lisko
Sorry for digging up this old thread, but i have the same problem with a broken switch console that i recently bought.
It came with a completely destroyed usb port and a flat battery, so of course it didn't fire up. I replaced the port and then quickly discovered that the m92t36 was faulty. Also somebody had previously opened the console and damaged the LCD connector. It had quite a few bent pins, so i replaced that as well. It still didn't boot up so i tried getting it into rcm and boom, it was alive. At least i could get into Hekate, do a NAND backup and also get the keys. Still, it doesn't boot any further. Backlight turns off after the sept logo but it doesn't shut down completely. Same as when trying to boot OFW, except the backlight doesn't even turn on then. I figured the previous owner must have messed with the NAND. So i wanted to try and rebuild it, when i stumbled upon the same error that was described in this thread.

Is it normal for memloader to freeze when the BQ24193 is faulty or could it be something else? The console charges normally and also displays a valid reading. I already ordered a few ICs from china but it might take a few weeks for them to arrive.
 
Last edited by kwnage,
I also have the exact same problem with one of my switches. I did a nand swap on another switch to restore the firmware through memloader which worked fine. But the switch still does not want to boot.

Anyone make any progress on this? I replaced the BQ24193 as well and it made no differrence.
 
I replaced the BQ on mine as well. Didn't make any difference.

Memloader doesn't seem to be able to initialise the USB interface. And to my knowledge that's connected directly to the Tegra. So maybe the Tegra is fried. But then again it seems to be able to boot the payload fine...
 
What I find odd that if it is a firmware issue the nintendo logo or the switch logo should pop up and freeze there. If neither of those are showing up as far as I know it is a hardware issue. I've been multimetering the f**k out of this things and there is nothing I can find that is irregular
 
On some units, it can be a bq24193 failure.

However, if you get 200,000(can't remember exactly integer) out of 4000000000(again, can't remember exactly) - this seems to indicate RAM failure.

Or at least something between tegra / ram.

I have a few units like this. I have @K1ck09 s unit here with this exact fault.

Originally a burnt bq24193.

Replaced this, max17050 fuel gauge had also failed(got burning hot) and took out the new bq24193.

So... Completely stripped and rebuilt bq24193 area and max17050 area... Fitted new fuel gauge.

Spent many many hours probing and scoping, absolutely everything tests correctly. Apart from the ram.

Memloader is failing at mtc_load, which is Minerva training cell.

Which seems to confirm diagnosis.

The next problem you are going to have is finding replacement ram chips.

But it appears if you are in this situation, it seems to be terminal.

I've spent hours and hours, looking through datasheets etc, and apart from replacing ram, which I have none, there is no solution.

If you replace the ram and still have the fault, then there is a fault within the tegra itself.

Dustbin time.

If I find anything new, I'll post.

I should add, you MAY get lucky reflowing the ram with new flux. But don't hold your breath.
 
Last edited by mattytrog,
  • Like
Reactions: kwnage and K1ck09
Damn. Mine hangs at mtc in memloader as well. Chances are it is the ram then.

I'll try a reflow and see if it helps any. If not i'll just use the board for spare parts.

EDIT: reflowed the ram, still same problem
 
Last edited by LOCtronics,
  • Like
Reactions: kwnage
I thought about reflowing the RAM, too. Didn't have the time yet.
But it really looks like it can't access a certain area of memory.

Could also be the Tegra since that could've been hit by the power supply putting 15 volts through the shorted USB data lines that my console most certainly had with its smashed USB port.
 
I thought about reflowing the RAM, too. Didn't have the time yet.
But it really looks like it can't access a certain area of memory.

Could also be the Tegra since that could've been hit by the power supply putting 15 volts through the shorted USB data lines that my console most certainly had with its smashed USB port.
The problem affects imem, thus TSEC. A ram reflow didn't work.

If replacing ram chips doesn't fix it, then it's internal in the falcon unit that has sustained damage.

Common factor appears to be overvoltage.

Interesting it didn't take the whole tegra out though. First bootloader is intact, so is Iram, at least partly. This is why we can run Hekate. Try getting your TSEC key. Error FFFFFFFF by any chance?

Open to suggestions. All passives test within limits.
 
I can get the TSEC keys. Everything works in RCM aside from memloader hanging.

I have to say though before this happend I was messing around with the docking station and different usb c chargers. Maybe that has caused some damage on the usb lines. The usb c port is fine and never had any problems.
 
I actually had a quick question regarding the nand rebuild. I've rebuilt it to 6.1 through the use of another switch. I would actually like to update the firmware to 6.2 as that is what was on the switch to begin with. Would it be possible to modify the prodinfo partition to work on another switch then update it to 6.2 and then change back the information to the defect switch?

If yes how would I go about things?
 
Last edited by LOCtronics,
I can get the TSEC keys. Everything works in RCM aside from memloader hanging.

I have to say though before this happend I was messing around with the docking station and different usb c chargers. Maybe that has caused some damage on the usb lines. The usb c port is fine and never had any problems.
I can use TegraRCMSmash. But the moment anything tries to access Falcon(assuming Falcon is pushing TSEC payload to ram), or any kind of Minerva training, it hangs.

HOWEVER, Hekate is using Minerva (though at a different point in RAM), so it seems so much ram is OK

Different chargers wouldn`t have caused it I wouldn`t have thought. The M92T36 would have died first.

Unless thats why it died, because M92T36 didn`t fail...

--------------------- MERGED ---------------------------

I actually had a quick question regarding the nand rebuild. I've rebuilt it to 6.1 through the use of another switch. I would actually like to update the firmware to 6.2 as that is what was on the switch to begin with. Would it be possible to modify the prodinfo partition to work on another switch then update it to 6.2 and then change back the information to the defect switch?

If yes how would I go about things?
No. We can rebuild prodinfo - ie replace / remove client cert, etc etc - but creating new Device cert(ECC-B233) offset 0x480, 180b in length, isn`t possible. At least I didn`t think it was.

If it is possible, I`d LOVE to hear about it. Can have full new prodinfos then...

EDIT:

In theory, you "could" copy/paste the old one and build the rest and calc the hashes, but you are using the wrong solution to your problem. If im understanding you correctly
 
Last edited by mattytrog,
If there was a possibility to check the nand with firmware 6.2 (as I have 8 fuses burnt) I could at least write that off of being the problem.

It would still not do anything about memloader not working. I get the feeling this board has had it days.
 
If something like memloader crashes, then it certainly is not a firmware/nand issue. It doesn't depend on anything that's on the eMMC. So basically it should work without an eMMC at all, even though it might not be useful then.
 

Site & Scene News

Popular threads in this forum