RGH Zephyr RGH1 Boots Xell perfect but dash only sometimes

knightmire

Junior Member
Oct 25, 2012
16
0
Ok, first off, I'm a long time lurker but first time poster. Hopefully no questions like this have been posted yet. I've been here so many times and never seen a post with this issue so I figure I'll post and hope for someone brilliant to read it.

Anyways, I've done so many RGH's and JTAGS i've lost count so I'm no newb but this is a first for me. I know, zephyr 4578's are a pain but I always try since non-updated systems are getting so rare.
So here's the situation; I just performed a RGH 1.1 on a Zephyr. Everything went well, used the shielded cable and a Coolrunner Rev C. Xell booted on first try, I got the key, created dash 16202 and wrote the nand in xell. I waited a couple mins and tested the dash boot where I noticed that booting that dash was rather hit and miss.

Now that I've put it back together and done more testing I realize it's only about 1 out of 8 tries that the dash boots up otherwise it just pulses forever or sometimes even stops pulsing but doesn't boot. If I press eject instead, I get insta-boot xell though! What's up with that? I tried changing the LDV a number up, even though I think if that was wrong it wouldn't boot it ar all right? I even made a second copy of 16202 and re-wrote it. Same result. Any ideas welcome. Gonna drive my poor friend nuts if I have to tell him to boot his system up to 8 times when he wants to get his game on! Help appreciated and thx in advance.
 

P Z U

VIP Member
Dec 14, 2012
165
0
California
Zephyrs are strange console that's why people only recommend rghing them for the keys. So if I where you I'd just test out different wire lengths and different wire positioning. Other then that there's to real sure fire way for them to boot constantly.
 

knightmire

Junior Member
Oct 25, 2012
16
0
Actually, I seem to have answered my own question. I have no idea why this works but I'd remembered doing something like this back when I RGH'd a similar system a good while ago. For some odd reason creating a freeboot image of dash 16197 boots instantly while the 16202 was sporadic at best. Why this is, I have no idea, I'd say maybe the image was corrupt but I tried twice just in case. Also, since jrunner makes perfect 16202 dashes for all the other systems I've done that doesn't seem to pan out either. I never solved why this worked last time I had to resort to it either.. Oh well, I'm cool with it running 16197 as it's not like anyone with an rgh spends much time on the original dash anyways, right? :)

Thanks for the answer though, I was ready to write it off as another zephyr-mystery-machine problem. So far I'm batting about 3 for 6 on Zephyrs I've done. So 50/50 they work or don't... Could be worse!
 

P Z U

VIP Member
Dec 14, 2012
165
0
California
Ill have to get a zephyr to play around with. Gives me another little project. Glad to hear you got it sorted out tho.
 

akawtu

Full Member
Dec 13, 2012
98
0
UK
If it's glitching fine (meaning the debug LED has stopped flashing) it's possible you are encountering the idle bug at POST 6F.

I discovered this bug recently but unfortunately it isn't widespread enough to warrant investigation by those who have the knowledge and understanding of kernel patches to fix it.

When the idle at 6F bug occurs it has glitched successfully and the boot code has run all the way to the kernel but it reaches POST 6F and it idles there for an unknown reason.

For my Falcon RGH2 it can idle for a random time period (can be a few seconds or a few minutes) but sometimes it idles indefinitely occasionally (so I power cycle after 10 minutes).

I suspected others would be encountering the bug and I suspect it hasn't been investigated because for others it mostly hangs so they are advised to fix it by messing with wiring.

If the debug LED stops flashing but it hangs, it likely means the idle at 6F bug has occurred and this can be confirmed by wiring up the UART. You can also hook up POST wires and read the POST code with a multimeter.

When it glitches successfully the UART output is "..![LF]". When it idles at 6F nothing else occurs on the UART until it stops idling. When it stops idling or it's a normal boot, the POST ends at 79 and DashLaunch loads and the UART output is "DashLaunch V3.06.507 started!".

I haven't tried dash 16197 but I will soon. I was testing with 14719 and 16202.

I don't have the tools to disassemble the kernel to have a look at the code and neither do I know anything about the xebuild patch system else I would have coded a patch already.