I dont have Hwfly to test, but i time some video on youtube, and it took 3 second from button press to hekate wait screen. This is double mosfet right, wonder if that makes the glitch time shorter.If we sees from the pattern it seems not. We might think that higher ns will result longer/unstable glitch, but NP2016 is the one people say hwfly use, and i assume its <15sec to glitch, eventhough they have the highest time spec.
Any place besides the capacitors next to the APU will be farther away and will then leave these capacitors in place to filter the voltage glitch itself (that is what capacitors do). You don't have access to the RPi source code so you can't modify the glitch timing to compensate.Another unrelated question, do you know equal point of the D mosfet other then the 2 point (cap) inside the apu shield?
I assume this is voltage regulated right, so it might be supplied by some voltage regulator. There is voltage regulator ic in the bottom, max77812 but it didn't connect to those 2 point cap. Not yet searching the backside of the pcb. The top one, i already check it one by one and none connected to it. I might buy a broken lite, to research further, so i didn't worry to broke something, since it already broke.
Hi bro. I have same issue. If you take a look at pico, it should still light up for some time after you’ve shut down. Hence it is not responsive when you immediately try to turn it on again because it is still shutting down.Hi everybody. First of all, thanks for clarifying the installation process. I got a rp2040 installed on my Mariko and it works flawlessly. There is however one thing that I think should not happen. Whenever I poweroff from the menu in ofw, next time I push the power button, the screen stays black. Then, I have to push power button for a few seconds and next time I turn the console on, hekate boots normally.
Any ideas about what could be causing this?
Check your SD card. It might be either fake or corrupted.View attachment 371181
i get this when i try to launch hakete, whats wrong?
I think what @MegaDeKay is saying (if I understand correctly) is that if we do not "hijack" the curent between the capacitor and APU we will not be able to make APU glitch because the capacitor will compensate the "delay" that mosfets are trying to create by shortening the D and S.I am not good at signal stuff.
Could you explain about this 'farther away' thing and the effect on the glitch timing.
Or any reference link that explain it.
For IRF8714 (installed on V2 switch) first time glitch was 3-4 seconds and all the consecutive ones were almost instant so less than 1sec (tested on more than 20 power cycles)I read the whitepaper of glitch on arxiv and the presentation of glitching the tegra, but didn't find that the signal of the gate might give an issue.
Comparing the datasheet also difficult, IRF using [email protected] while AON using 10V
Lets say we add the total time (turn on delay + rise time + turn off delay + fall time)
[email protected]
IRF8342: 31.1ns
IRF8714: 35.9ns
NP2016: 86ns
VGS@10V
AON7400: 40.1ns
AON6512: 56.1ns
If we sees from the pattern it seems not. We might think that higher ns will result longer/unstable glitch, but NP2016 is the one people say hwfly use, and i assume its <15sec to glitch, eventhough they have the highest time spec.
Post automatically merged:
The base of why i think Rds is important because the apu have impedance. And in here we make a parallel circuit. So the resistance of the mosfet, will also affect how much the current flows to that point (i assume its somekind of the VDD of the processor). First i think that the lesser the current flows to the apu the better, that why i think 6512 is the best of all, since it is the most less resistance, so majority of the current will be goes to the mosfet. But from your finding, i might be wrong. The current flows in the apu must be at some range, for the glitch to work flawlessly.
I actually did essentially this exact thing on the last lite I hacked.
I bought it off ebay from a dad who forgot the parental control pin (who knows if that's the legit story, Idrc) and I installed Picofly, booted into CFW emmc, used an app to remove parental controls, and then reset the console through the menu in Horizon.
After that I went back to Hekate and started the usual process of backing everything up and making an emuMMC.
Great thanks, it's not dangerous... but i use Sysnand not emuMMCWell yeah, that seemed like the logical way to go about it although we didn't have a chance to do it before.
Thanks for confirming, will be usefull in the future for sure and I'm sure @chronoss appreciates the answer aswell![]()
if you dont use emunand then just do a normal reset from sysnand and you are set.Great thanks, it's not dangerous... but i use Sysnand not emuMMC![]()
Ok thanks !!!if you dont use emunand then just do a normal reset from sysnand and you are set.
To be clear, emmc is NOT the same as emuMMC. I booted into sysnand (on the emmc chip, not emummc on the SD card) to do these things with cfw (atmo) enabled.Great thanks, it's not dangerous... but i use Sysnand not emuMMC![]()
Yes i have look and it seems doesnt have any, if of course every image layer have the exact coordinate.Yes.
If it have vias, i don't think it could get ripped easily, since it has anchor deep down in the layer
I am sure it is. Since thats the required component which is missing.
Because the cmd is disconnected, then the apu can't R/W to the EMMC, and throws that purple. Just like what those on reddit says, its about kernel panic, or something wrong with the bootloader.
Ive just blindly tried it with top resistor from pico.. and.. it works.... glad.. although the instalation is a bit mess n hack..For oled its 4.7k, I think its the same with lite. I might measure it later, still at work now.
https://gbatemp.net/threads/switch-oled-missing-the-cmd-capacitor.603541/