I opened the console which was virgin, installed rp2040 directly and immediately worked with hekate......the problem is not in the screens it is in the installation....but we are getting lost in futile things....the problem is the firmware..... it takes experience to do certain jobs that's all
Has anyone started some sort of git repository. If so, I would like to take a look at it.
im using stock Hekate.....and stock atmosphere for reference.. and the sd card is a 128gb Sandisk Extreme Pro.
originally i would of agreed with you BUT now we have a user who has sx/hwfly working but not pico....so there is something that is obviously a miss. im still not 100% convinced its not a bad install but we need to get to the bottom of this before everyone and there mom's start trying to install these and fail.....
can i see a picture of the install.Well, I’ve already made that on my first try to install rp2040. I had lite with Sx lite. Wired the rp2040 to the solder points as it was on diagram, used already installed cpu flex (Sx orig) - nothing. -> several diode mode readings, resoldering, getting rid of Sx smal upper flex (for emmc and rst points) - nothing. -> just soldered back Sx lite (on wires) - boots like a charm. I thought that may be sx chip is bringing some TX shit code to boot0, and swapped chip to hwfly 4.2 with latest firmware - boots like a charm (with the same wires as it was on rp2040 install). Next I thought that may be I need a virgin console, unsoldered hwfly and updated sysnand to latest firmware (15.0.1). -> soldered rp2040 - nothing. Tested with V2 hwfly flex - nothing. Tested with bare mosfet (from hwfly flex) soldered by wires without removing vertical cap as it was on diagram - nothing. Took another rp2040 - same result… and that was the point were I decided to give up and try later.
P.S. Again, the only thing that I believe could have affected this install is thin and relatively long 36awg wires on cpu mosfet controlling point.
Perhaps the firmware uses a fixed or narrow timing window and isn't able to calibrate timings for consoles that aren't close to the one the original dev was working with. That would mean CPU point's wire type and length would greatly influence success.
this also makes sense aswell to me aswell. i think until we know what the original or ubuntu firmware is doing we wont be able to acctually tell.
I recall the Xbox 360 RGH chips had a fixed timing and they were *very* sensitive to wire length, the Xecuter QSB had a handful of pads for calibrating glitch line length.
My wire length isn't as short as it could be... But it's much shorter then it was when I originally installed, I'm using kynar aswell
Nah I think it's safe to say Tafty's is working. The firmware definitely does things, it'll reset my console if the CPU line is disconnected.Unless @Tafty is trolling and has edited his video
Sorry I didn‘t read all the replies of today, why do you guys want to read the emmc?
To know for certain if it's actually writing to it, it seems that for some of us it's failing on some stage
Aah I see, yeah that‘s probably the only way unless we write a firmware that just dumps the boot0 content over the UART interface on the rp2040
that would be extremely weird because all eMMCs use a standardized protocol
The protocol is the same, but sometimes there are differences. There might be some oddity stopping it from supporting certain eMMCs, they are all a tiny bit different and have their own quirks, though communication and pinout is supposed to be the same.
@
Skelletonike:
@
Skelletonike:
