Separate names with a comma.
Discussion in 'Switch - Console, Accessories & Hardware' started by dicamarques, Mar 4, 2017.
We will start a GoFundMe for you! Btw, you have another sub on YT
WHOA!!! This is a much better picture. Shit, that ain't no flex cable. That is an actual PCB. The other pic I saw made it look like it was a flex cable. Well, that makes a BIG difference there.
it's built in support for arm7 in the cpu, Nintendo has to actually implement that unless we know how which we don't really right now.
C'mon boiz! Time to break out the soldering irons and fuck with some eMMC chips!
Either way. Flex cable or not, BGA chips suck to solder. I have the tools for it because I bought a whole bunch of shit when I was fixing the xbox 360's RROD. I would still likely solder directly to the motherboard instead of fucking around with solder balls and shit. They can be very time consuming.
If anyone wants to learn about this lovely CPU. also the tools, software, ect it can come with.
After watching Louis Rossmann. I don't even understand how you guys got the paient with solidering balls. Must suck really, really hard.
Yes. It sucks.... balls. LOL. I just had to.
The thing that really sucks is every company tries to be ROHS compliant, but non leaded solder is terrible. It isn't as flexible which was the issue that caused the RROD because the balls would crack off the solder pad during the thermal expansion. I replaced many balls with leaded solder balls instead and that would permanently cure the issue. THe problem was the amount of time I had to put into the work wasn't worth the amount I could make off of a repair. So after just a few months of that I quit working on the 360's.
Oh you... I knew you would go there
I can understand that. I actually don't know why they're moving away from leaded solider. Must be with health and environmental stuff.
Have you had any jobs repairing the PS3s that had a similary issue with YLOD?
Yes, but only like 2 or 3. I could have done hundreds of 360's if I wanted to but I only bothered with a few dozen before seeing that I wasn't making very much for my time I put into it. That was around the time that I went full into to doing the wii repairs, and I made shit tons of money there.
My favorite thing is soldering while hammered. I got to the point that I could get so drunk that I couldn't walk, but I could somehow still do the fine soldering that was needed for wii repairs.
Because we don't have the recovery images Nintendo used to repair consoles nor we can create our own since they are signed.
It would be interesting to find an emmc module from a dev unit.
Also it'd be interesting to se if you can image one emmc to another and use in the unit the image is from or if there is additional security above and beyond signing. If it's just signing you should be able to use an new eMMC module with an exact copy of the original emmc on it. If so then getting a larger devkit emmc and imaging that with the original to se if it opens up the additional internal storage.
Hmmm Hopefully someone finds a way to get a bigger eMMC on there.
Wiiu had it. The SEEPROM last bytes contains the boot1 expected version.
Dunno why Nintendo didn't apply this check on 3ds...
I'd assume because they didn't think of it at the time
You will not be able to use an eMMC module from a devkit in a consumer model switch. Boot0 will check the hash of boot1. Devkits and consumer models will have different boot0 and boot1 making them incompatible with eachother. And chances are the hardware will be different enough to make them incompatible with eachother.
Im talking about overwriting the larger dev emmc completely with the consumer image that included boot0. I've worked with eMMC on the ODroids so I'm familiar with how they work with Arm SoC. It is possible they do something to prevent it, but we wont know that till we try. I don't think anyone will be getting a dev eMMC soon but it might be possible to just build a larger eMMC and the switch may even recognize larger eMMC than what we expect. We don't know what size the OS will address at this point.
It has always been that boot0 is written on the ARM die, never the flash memory. Boot1 is on the flash memory. I also would doubt that the devkit would have a larger flash size, but that I could certainly be wrong about.
Boot0 is hardcoded and can not be changed. Boot0 checks the hash of boot1 and compares it to a hash value written in the OTP. So with that, boot1 can not be altered either unless a hash collision can be found... and fat fucking chance on that one.
It was a bug in boot1 on the wii that allowed hackers to write their own boot2 code. Boot1 also checks the hash of boot2, but boot2 is meant to be able to be upgraded.
Now, this is all experience from what past consoles have had set up and Nintendo certainly could have done things differently but I expect that they likely did things the same way. Why reinvent the wheel, right? But also, there does need to be a chain of different level boot loaders. Each one has a different purpose of what they check and initialize.
Dev kits have 64GB
Best case scenario is that the Switch wouldn't notice the extra space on the 64 GB eMMC because the (signed) partition table from the retail eMMC image is configured for 32 GB.
Worst case is it wouldn't boot because the eMMC's CID is used as part of the encryption.