Picofly AIO Thread

  • Thread starter Thread starter Adran_Marit
  • Start date Start date
  • Views Views 763,404
  • Replies Replies 3,575
  • Likes Likes 64
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.
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.
But hey, even on Lite vs V2, the same mosfet the glitch is longer on V2, so maybe device unit dependent, as long as it still under 5s which maybe the average people tolerance when looking at bsod screen after they turn on their device.
 
Last edited by cgtchy0412,
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.
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.

You are free to give it a try, but I suspect those two points were selected for a very good reason.
 
  • Like
Reactions: abal1000x
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?
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.
Post automatically merged:

View attachment 371181
i get this when i try to launch hakete, whats wrong?
Check your SD card. It might be either fake or corrupted.
 
  • Like
Reactions: QuiTim and Vivi34
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.
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.
So basically doing this mosfet "trick" anywhere alse except between Caps and APU will be pointless.
Post automatically merged:

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.
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)
For IRF8342 (single mosfet installed on V1 unpatched) the glitch is taking at least 6-7 second all the time (tried it for at least 15 power cycles)
 
Last edited by QuiTim,
  • Like
Reactions: abal1000x
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.
Well 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 :D
Great thanks, it's not dangerous... but i use Sysnand not emuMMC :(
 
anyone using v1 on v2/lite .? sprti ny easier?
 

Attachments

  • Screenshot_2023-05-16-15-26-51-601_com.google.android.youtube.jpg
    Screenshot_2023-05-16-15-26-51-601_com.google.android.youtube.jpg
    1.1 MB · Views: 70
  • Love
Reactions: chronoss
Please help, i need to repair broken rst point , what should be the technique.
Also what value the cap/resistor on alternate point on the right.
Its gives purple screen when i boot it up.
 

Attachments

  • 20230516_174945.jpg
    20230516_174945.jpg
    624.7 KB · Views: 65
Actually ripped part is only in red circle, so it doesnt have any vias. Should be safe to leave it then ?.
It seems it has vias.
Any jumper point can be used to restore this connection?

And it means that purple screen is cause by cmd traces not connected because missing resistor?
And anyone know the value of this cmd line resistor?
1684236757269.png
 
Last edited by cgtchy0412,
Yes.
If it have vias, i don't think it could get ripped easily, since it has anchor deep down in the layer :lol:


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.
Yes i have look and it seems doesnt have any, if of course every image layer have the exact coordinate.
Please help measure the value as i lost the original one.
 

Attachments

  • 20230516_192050.jpg
    20230516_192050.jpg
    418.4 KB · Views: 59
  • 20230516_192034.jpg
    20230516_192034.jpg
    341.9 KB · Views: 63

Site & Scene News

Popular threads in this forum