What's new

Solved Custom XeBuild INIs for building Glitch Images of Lower Dashes?

  • Thread starter SGCSam
  • Start date
  • Views 13,665
SGCSam

SGCSam

Enthusiast
Messages
275
Solutions
1
Reaction score
25
Points
95
Sin$
7
Hey Everyone,

I thought I'd preface this with as I'm discussing XeBuild, my console is an RGH1 exploited Falcon and NOT a retail, just thought I'd get that out of the way :tongue: (Also, just in case it's needed, my CB is 5771, LDV is 7)

So essentially, correct me if I'm wrong, but here's my generic and brief understanding of how RGH works: We're sending a small electrical pulse to the CPU to slow it down, and trick the CD verification to return true, in order for us to run a modified CF image to allow the execution of unsigned code.

With that in mind, assuming the CD verification passes, what should stop me from running any hacked CF image, on any dashboard version?

So in context, assuming I can create my own glitch.ini file for a lower dash in XeBuild and I have the filesystem for the Dashboard in question, could I theoretically create a NAND flash image of, say, 2.0.9199 for my RGH1? This is an issue at the moment as I can only create JTAG images for this dashboard and not RGH1 images (because the dash is so old), hence I'm trying to solve that.

Now, you might ask why I'd want to do such a thing. I already know and am totally aware that I cannot run newer games if I was to go back to a kernal that old. The reason being is because I'm recreating several UI elements from the older dashes and would ideally like to use them as source material. There's most likely a better way as well in terms of accomplishing the task, but I feel it'd also be quite a cool technical achievement as well as being cool to see the older dashes again :tongue:. I don't intend to keep it massively long term, so I'm not wasting my RGH for the sake of an older dash.

But yeah, if I have the dashboard filesystem, would it be possible for me to create a glitch.ini and hence a glitch image of older dashes to run on my RGH1?

If so, would someone be able to explain briefly how I'd go about performing it and/or linking me to some resources where I could learn myself? I'm not wanting a step by step guide (as I don't want to take up your time), just simply some explanation of whether such a thing is possible.

tl;dr Can I run old dashboards like 9199 on an RGH1 by building my own glitch.ini file, as XeBuild can't create RGH1 images for these older kernals?

Thanks!
 
TEIR1plus2

TEIR1plus2

VIP
VIP
Hidden Devils
Frame In Gold Programmer A Milli
Messages
510
Reaction score
224
Points
305
Sin$
0
WTF did i just read?

you can boot to any dashboard as long the system it self can run it, with the rgh/smc(jtag) hack.
ie xenon can run anything 1888+ where jasper can't run that far down.

If you want the old dash to be hacked you must port the patches or run it with out any.

Edit: also about needing to be rgh2 for to hack the cb_2 is pointless, since its rgh1 all he needs to do is either run an older CD or run a hacked one to run the older kernels.
FYI on your signature, the GPU Jtag was actually used in the smc hack. The header that you solder the diodes to is the GPU Jtag and it has stuff soldered on it connecting different ports that the smc has access to so that the smc can use the GPU Jtag.
 
Last edited:
SGCSam

SGCSam

Enthusiast
Messages
275
Solutions
1
Reaction score
25
Points
95
Sin$
7
The patch files follow a specific pattern/struct layout
Code:
struct
{
    u32 PatchOffset;
    u32 InstructionCount;
    u32 Instruction[InstructionCount];
} PATCHES;

struct
{
    PATCHES PatchesCBB[num_of_CBB_patches]; // cbb patches
    u32 EndCBB = 0xFFFFFFFF;
    PATCHES PatchesCD[num_of_CD_patches]; // cd patches
    u32 EndCD = 0xFFFFFFFF;
    PATCHES PatchesHV[num_of_HV_patches]; // HV/Kernel patches
    u32 EndHV = 0xFFFFFFFF;
};
Thats for g2 patch files, other exploits have more patches
I have the patches for my old trinity labeled as an example, I would recommend you brush up on PPC for this so you know whats being patched and can port them

trinity patches for IDA 6.8:
[Click here to view this link]
Virus Scan: https://www.virustotal.com/#/file/b...58add91d639c623d39d50ca0534b0ac2bd773/details

after looking at the rgh2 patches, it does look a lot easier to do it with rgh2, you'd just use the CF and CG for 9199 and copy the HV/Kernel patches over the HV/Kernel patches in the targetted patches file.

Thanks TEIR1plus2 TEIR1plus2 , I downloaded and opened your Trinity patch file in IDA and could see the comments you made, that's really useful.

So if I'm correctly interpreting what you're saying, as RGH2 only needs me to replace the HV/Kernal patches, could I take a normal patches_g2falcon.bin file from 17511, then replace the HV/Kernal patches section with those present in the 9199 JTAG patches (I think that'd be just patches_falcon.bin) and the console should boot?

Assuming that's the case, it sounds easy enough. The ONLY thing that'd be an issue is identifying where in the JTAG patch file the HV/Kernal patches begin. Similar to the struct code you sent for RGH2, do you know of the JTAG patch file structure? That way, I should be able to find the HV/Kernal patches in the JTAG patch file and then use them to replace the HV/Kernal patches in the RGH2 patch file. Hopefully, the console should then boot and the job will be done.
 
ddxcb

ddxcb

Contributor
Messages
1,647
Reaction score
275
Points
285
Sin$
0
Thanks TEIR1plus2 TEIR1plus2 , I downloaded and opened your Trinity patch file in IDA and could see the comments you made, that's really useful.

So if I'm correctly interpreting what you're saying, as RGH2 only needs me to replace the HV/Kernal patches, could I take a normal patches_g2falcon.bin file from 17511, then replace the HV/Kernal patches section with those present in the 9199 JTAG patches (I think that'd be just patches_falcon.bin) and the console should boot?

Assuming that's the case, it sounds easy enough. The ONLY thing that'd be an issue is identifying where in the JTAG patch file the HV/Kernal patches begin. Similar to the struct code you sent for RGH2, do you know of the JTAG patch file structure? That way, I should be able to find the HV/Kernal patches in the JTAG patch file and then use them to replace the HV/Kernal patches in the RGH2 patch file. Hopefully, the console should then boot and the job will be done.

RGH1 uses CD patch then HV/kernel patches.
smc/jtag uses 1bl,cb,cd,HV/Kernel.

also the only patches needed to port over is the hv/kernel since 9199 was hacked for smc/jtag. any others before need new patches or none for retail. (CD might need to be modded or use older one to boot pre-9199.
 
TEIR1plus2

TEIR1plus2

VIP
VIP
Hidden Devils
Frame In Gold Programmer A Milli
Messages
510
Reaction score
224
Points
305
Sin$
0
RGH1 uses CD patch then HV/kernel patches.
smc/jtag uses 1bl,cb,cd,HV/Kernel.

also the only patches needed to port over is the hv/kernel since 9199 was hacked for smc/jtag. any others before need new patches or none for retail. (CD might need to be modded or use older one to boot pre-9199.
CD can be what ever, it doesn't do any init, just patches. the hardware init happens in cb so if thats what stops him then he's sol anyways.
How does the console patch the 1bl?

HV/Kernel patches are the last patches. so look for the 2nd to last 0xFFFFFFFF and the patches you want will start after that.
 
ddxcb

ddxcb

Contributor
Messages
1,647
Reaction score
275
Points
285
Sin$
0
CD can be what ever, it doesn't do any init, just patches. the hardware init happens in cb so if thats what stops him then he's sol anyways.
How does the console patch the 1bl?

HV/Kernel patches are the last patches. so look for the 2nd to last 0xFFFFFFFF and the patches you want will start after that.

hes running rgh1 so the console is trying to glitch the cb to run the modded cd.
on the smc/jtag after the console does it thing and boot the 4532k and run the rebooter code to patch 1bl to hv/kernel.
 
SGCSam

SGCSam

Enthusiast
Messages
275
Solutions
1
Reaction score
25
Points
95
Sin$
7
So, TEIR1plus2 TEIR1plus2 and ddxcb ddxcb , just to confirm - I'm running RGH1 on my system. My _glitch.ini for 9199 is identical to a 17511 _glitch.ini, excluding the fact I've changed CF and CG (so CB, CD and CE are the same as 17511) to 9199, I've changed the security section to remove 17511 security files and add odd.bin, and then changed the flashfs section to the 9199 files.

As ddxcb ddxcb said, RGH1 uses a patched CD then a patched HV/Kernal. If my console is finishing the glitch (my chip stops pulsing) and I can access XeLL, but the boot process does NOT complete (I see nothing on the screen, the Ring of Light animation and bootanim doesn't play and I get no RROD error), this would suggest my HV/Kernal patches are wrong, correct? As per http://free60.org/wiki/Boot_Process, the error has to be occurring in either CF or HV/Kernal but as I'm using a CF that was used in JTAG, my logic leads me to conclude the HV/Kernal is the issue here, hence my patches must be wrong.

Now, again to make sure, as 9199 had patches for the JTAG hack and as I am currently using RGH1, I can take a 17511 patches_fat.bin file for RGH1 which will patch the CB and CD that I'm using. The ONLY thing I'd have to change inside patches_fat.bin for my RGH1 image would be the HV/Kernal patches, correct?

So, if that's the case, all I need to do now is go into the 9199 patches_falcon.bin file used to patch the bootloaders for the JTAG hack, find the HV/Kernal patches inside of there, and then copy and replace the RGH1 HV/Kernal patches inside of patches_fat.bin?

Assuming that's true, that leads me to a potential caveat. TEIR1plus2 TEIR1plus2 , when I opened both patches_falcon.bin for JTAG and patches_fat.bin for RGH1 in IDA, both of them had the 0xFFFFFFFF sequence of bytes viewable in hex. Is it safe to assume that although you said this was used to show the end of each patch section in RGH2 patches_g2.bin files that this still applies to JTAG and RGH1 patches?

Therefore, my understanding leads me to this: I copy over the patches_falcon.bin for RGH1 from 17511. As I'm using the CB, CD and CE from 17511 in my _glitch.ini that I created for 9199, I can leave those sections of the patches alone. But, as I'm using 9199 for CF and CG, I need the HV/Kernal patches used in the original 9199 JTAG image. To do that, I find the second last 0xFFFFFFFF sequence of bytes in patches_fat.bin for RGH1 and delete everything after that. Then, I open the patches_falcon.bin file from JTAG and find the second last 0xFFFFFFFF sequence of bytes in there. I finally copy everything after those sequences of bytes from the patches_falcon.bin from JTAG, and paste them into patches_fat.bin for RGH1. I should then have everything I need for my valid patch file hence I should be able to create the image in XeBuild, flash it over to my console and have the boot process complete fully and load into 9199.

That may sound very confusing as we're talking about a lot of files and changing stuff around, apologies :tongue:
 
Last edited:
TEIR1plus2

TEIR1plus2

VIP
VIP
Hidden Devils
Frame In Gold Programmer A Milli
Messages
510
Reaction score
224
Points
305
Sin$
0
The patch structure is always the same yes. The difference is how many patches and patch sections and the order of the sections.

You need a post sniffer to know exactly where it fails.
 
SGCSam

SGCSam

Enthusiast
Messages
275
Solutions
1
Reaction score
25
Points
95
Sin$
7
The patch structure is always the same yes. The difference is how many patches and patch sections and the order of the sections.

You need a post sniffer to know exactly where it fails.

With a POST sniffer, I have to read the pinout points on the back of the motherboard, bit order from 7 to 0 (i.e. from FT6U8 to FT6U1 on the back of the motherboard). I can then assemble those bits into a byte in binary, then translate that into hex and determine the POST code as per http://free60.org/wiki/POST.

Now on that page, it says I can read each point with a simple multimeter to assemble the byte which seems easy enough. The only thing that confuses me is "The POST bus holds the last code's bits all the time".

What defines all the time? As in the whole time the console is powered on, the whole time the console has standby power attached, or literally all the time since the last boot? This is more of an electrical/engineering question which isn't exactly my speciality so excuse my noobness :tongue:
 
TEIR1plus2

TEIR1plus2

VIP
VIP
Hidden Devils
Frame In Gold Programmer A Milli
Messages
510
Reaction score
224
Points
305
Sin$
0
With a POST sniffer, I have to read the pinout points on the back of the motherboard, bit order from 7 to 0 (i.e. from FT6U8 to FT6U1 on the back of the motherboard). I can then assemble those bits into a byte in binary, then translate that into hex and determine the POST code as per http://free60.org/wiki/POST.

Now on that page, it says I can read each point with a simple multimeter to assemble the byte which seems easy enough. The only thing that confuses me is "The POST bus holds the last code's bits all the time".

What defines all the time? As in the whole time the console is powered on, the whole time the console has standby power attached, or literally all the time since the last boot? This is more of an electrical/engineering question which isn't exactly my speciality so excuse my noobness :tongue:
When the CPU has power, meaning when the console is on. You can read it with a multimeter, but if the POST ends up being 0xAE then you'll need a sniffer to see the post before that. 0xAE is a general exception vector that triggers when something went wrong somewhere. Can be anywhere before the HV is loaded.
 
SGCSam

SGCSam

Enthusiast
Messages
275
Solutions
1
Reaction score
25
Points
95
Sin$
7
When the CPU has power, meaning when the console is on. You can read it with a multimeter, but if the POST ends up being 0xAE then you'll need a sniffer to see the post before that. 0xAE is a general exception vector that triggers when something went wrong somewhere. Can be anywhere before the HV is loaded.
Ok, that's cool. The elephant in the room with regards to the multimeter is that the points are on the back of the motherboard. If I wanted to probe them with the multimeter, the console would have to be on making it a pain to physically access those points. At a minimum, I'd have to turn the console on outside of the metal chassis which I don't feel at all comfortable attempting (when I perform any work, an RGH, LED mod, etc, I ALWAYS have the console inside the chassis with the fans and fan duct in place before powering on the console).

Is there any sort of standardized POST sniffer I can purchase or is it really up to me to develop a homemade one myself?

Theoretically, creating one would be straightforward logically - just connect a wire to each POST point and if there's a voltage then I have a 1, else I have a 0. I was possibly thinking of then wiring that up to some sort of 7-segment display and writing a small script to display the POST code, perhaps with a small microcontroller such as an Arduino. The main issues there obviously are wiring routing from the POST points, how I handle wiring up each wire to whatever device I use, how I handle powering said device then how the device itself handles the signals from the wires and hence constructs the byte value. Of course, that's simply an idea that may not even be feasible.
 
TEIR1plus2

TEIR1plus2

VIP
VIP
Hidden Devils
Frame In Gold Programmer A Milli
Messages
510
Reaction score
224
Points
305
Sin$
0
Ok, that's cool. The elephant in the room with regards to the multimeter is that the points are on the back of the motherboard. If I wanted to probe them with the multimeter, the console would have to be on making it a pain to physically access those points. At a minimum, I'd have to turn the console on outside of the metal chassis which I don't feel at all comfortable attempting (when I perform any work, an RGH, LED mod, etc, I ALWAYS have the console inside the chassis with the fans and fan duct in place before powering on the console).

Is there any sort of standardized POST sniffer I can purchase or is it really up to me to develop a homemade one myself?

Theoretically, creating one would be straightforward logically - just connect a wire to each POST point and if there's a voltage then I have a 1, else I have a 0. I was possibly thinking of then wiring that up to some sort of 7-segment display and writing a small script to display the POST code, perhaps with a small microcontroller such as an Arduino. The main issues there obviously are wiring routing from the POST points, how I handle wiring up each wire to whatever device I use, how I handle powering said device then how the device itself handles the signals from the wires and hence constructs the byte value. Of course, that's simply an idea that may not even be feasible.
You could take it out and flip it over with the fan and fan duct still in the correct place but upside down. That's what I do. You can use an arduino to read the post but the post runs at 1.2v and arduino is at 5v. you'll need a level shifter. JRunner has a post sniffer.
 
SGCSam

SGCSam

Enthusiast
Messages
275
Solutions
1
Reaction score
25
Points
95
Sin$
7
You could take it out and flip it over with the fan and fan duct still in the correct place but upside down. That's what I do. You can use an arduino to read the post but the post runs at 1.2v and arduino is at 5v. you'll need a level shifter. JRunner has a post sniffer.

Cool - I should have been more precise. I'm actually using a WeMos D1 R2 rather than an Arduino (sorry, shouldn't have used that generically).

I believe the WeMos actually runs at 3.3V, but I'm not sure if that'll let me get away with HIGH and LOW being within a valid range to not have to use a Level Shifter (my basic understanding of a Level Shifter is that it essentially converts the HIGH and LOW used by the 5V powered microcontroller to the representative HIGH and LOW used by the 360).

I believe LOW is defined as sub 1V with 3.3V boards, and HIGH is defined as being greater than 2V (https://www.arduino.cc/reference/en/language/variables/constants/constants/). As per http://free60.org/wiki/POST, the POST points seem to run at 1.2V to 1.8V which puts in bang in the middle of both definitions. That's interesting - ideally, will it default to HIGH (otherwise, it'll be off so 0V and hence LOW)?

I have gone ahead and written my own sketch for my board - I could have used J-Runner but, quite honestly, I felt it'd be quite fun to attempt on my own. Programming is my main area so that's probably reason enough :tongue:

Assuming that the different definitions of LOW and HIGH for my 3.3V board do NOT let me get away with not using a Level Shifter, do you have any particular recommendation of a specific one I could pick up? I think there's actually a tutorial for creating your own on free60 but I'd rather avoid that route if I can. Again, I'm not too orientated to electrical engineering so your answer could well be "All shifters are the same, just pick X or Y or Z" and I'm massively overcomplicating this, but yeah :tongue:
 
TEIR1plus2

TEIR1plus2

VIP
VIP
Hidden Devils
Frame In Gold Programmer A Milli
Messages
510
Reaction score
224
Points
305
Sin$
0
Cool - I should have been more precise. I'm actually using a WeMos D1 R2 rather than an Arduino (sorry, shouldn't have used that generically).

I believe the WeMos actually runs at 3.3V, but I'm not sure if that'll let me get away with HIGH and LOW being within a valid range to not have to use a Level Shifter (my basic understanding of a Level Shifter is that it essentially converts the HIGH and LOW used by the 5V powered microcontroller to the representative HIGH and LOW used by the 360).

I believe LOW is defined as sub 1V with 3.3V boards, and HIGH is defined as being greater than 2V (https://www.arduino.cc/reference/en/language/variables/constants/constants/). As per http://free60.org/wiki/POST, the POST points seem to run at 1.2V to 1.8V which puts in bang in the middle of both definitions. That's interesting - ideally, will it default to HIGH (otherwise, it'll be off so 0V and hence LOW)?

I have gone ahead and written my own sketch for my board - I could have used J-Runner but, quite honestly, I felt it'd be quite fun to attempt on my own. Programming is my main area so that's probably reason enough :tongue:

Assuming that the different definitions of LOW and HIGH for my 3.3V board do NOT let me get away with not using a Level Shifter, do you have any particular recommendation of a specific one I could pick up? I think there's actually a tutorial for creating your own on free60 but I'd rather avoid that route if I can. Again, I'm not too orientated to electrical engineering so your answer could well be "All shifters are the same, just pick X or Y or Z" and I'm massively overcomplicating this, but yeah :tongue:
3.3v will kill a 1.2v system. On phats the POST is supposed to be 1.2v and slim is supposed to be 1.8v. But I've seen my jasper have 1.5v. I've also seen it have 1v.
 
SGCSam

SGCSam

Enthusiast
Messages
275
Solutions
1
Reaction score
25
Points
95
Sin$
7
3.3v will kill a 1.2v system. On phats the POST is supposed to be 1.2v and slim is supposed to be 1.8v. But I've seen my jasper have 1.5v. I've also seen it have 1v.
Ok, good to know - I was thinking that might be the case. So as the voltages seem to vary between 1.2V and 1.8V then I'm going to have to logically generalize my low voltage.

From what I understand about the Level Shifter, I could purchase something such as this: https://www.ebay.co.uk/itm/TXS0108E...874380?hash=item5d6d5e980c:g:fssAAOSwLEtYjK-a

On the high voltage side of the Level Shifter (in the above case VCCB), I'd run my wires from the B pins to my WeMos's digital pins. Then, I'd connect my POST wires to the A pins. I'm assuming the VA and VB pins are supply voltages for each side, so if that's the case, I should be able to connect the VB side to a 5V pin on the WeMos, and the VA side to a 3.3V point on the 360's motherboard (not sure if that's how that works - let me know if I've made a mistake). Finally, I'd connect the B side ground to a ground pin on the WeMos and the A side ground to a ground point on the 360 and it should automatically convert from the 360's POST voltage to the WeMos's voltage.

I should also add I am NOT foolishly attempting this right on my RGH - I have a test console that I can use (a really old Zephyr) that still boots but is certainly on the RROD horizon.

Is that correct, am I missing anything?
 
Last edited:
As an eBay Associate we earn from qualifying purchases.
TEIR1plus2

TEIR1plus2

VIP
VIP
Hidden Devils
Frame In Gold Programmer A Milli
Messages
510
Reaction score
224
Points
305
Sin$
0
you would use the voltage that the logic runs at. if the logic runs at 5v, you'd use a 5v source. if it runs at 1.8v you'd use a 1.8v source, not a 3.3v
 
SGCSam

SGCSam

Enthusiast
Messages
275
Solutions
1
Reaction score
25
Points
95
Sin$
7
Ok, good to know - I was thinking that might be the case. So as the voltages seem to vary between 1.2V and 1.8V then I'm going to have to logically generalize my low voltage.

From what I understand about the Level Shifter, I could purchase something such as this: https://www.ebay.co.uk/itm/TXS0108E...874380?hash=item5d6d5e980c:g:fssAAOSwLEtYjK-a

On the high voltage side of the Level Shifter (in the above case VCCB), I'd run my wires from the B pins to my WeMos's digital pins. Then, I'd connect my POST wires to the A pins. Finally, I'd connect the B side ground to a ground pin on the WeMos and the A side ground to a ground point on the 360 and it should automatically convert from the 360's POST voltage to the WeMos's voltage.

Is that correct, am I missing anything?
you would use the voltage that the logic runs at. if the logic runs at 5v, you'd use a 5v source. if it runs at 1.8v you'd use a 1.8v source, not a 3.3v
Ah, I understand, thanks! Again, bit of a noob question but this certainly isn't my main area of expertise.

You said it yourself however, some Jaspers you've seen have ran 1.5V, some consoles have run at 1V but they are supposed to run at 1.2V. I've had a look via google and can't find any images that are still present on the relevant forums - do you know of any applicable power sources I can solder to on the 360 to supply power to the low voltage side of the Level Shifter?
 
As an eBay Associate we earn from qualifying purchases.
SGCSam

SGCSam

Enthusiast
Messages
275
Solutions
1
Reaction score
25
Points
95
Sin$
7
use a voltage divider on a 3.3v source
Alrighty, will do!

It'll probably be a few days before I acquire everything I need but I'll make a post in this thread after my initial testing on the Zephyr I mentioned. If it goes well, I may attempt it on my actual RGH. If it doesn't go well, then it may be time to quit while I'm ahead. Personally, I don't hold out much hope myself but I think attempting it will be fun nonetheless. Fingers crossed this goes well :biggrin:

Anyway, again, thanks so much for your help TEIR1plus2 TEIR1plus2 !
 
SGCSam

SGCSam

Enthusiast
Messages
275
Solutions
1
Reaction score
25
Points
95
Sin$
7
Bump. So a quick update, I abandoned my Arduino POST Sniffer idea - the whole circuit and setup was quite clunky and unreliable so I've reverted to the simple multimeter method.

TEIR1plus2 TEIR1plus2 , I actually expanded a bit on your method of holding the console upside down - I took an old chassis I had laying around and drilled a section out of it which corresponded to the cut out area of the chassis being exactly where the POST points were on the back of the motherboard. This enabled me to secure the motherboard, fan and fan duct in place screwed into the chassis (minus 1 X-Clamp screw as that screw hole was in the cut out area, shouldn't be a huge deal) then place the chassis upside down and probe the POST points with a multimeter through the cut out area.

So, I flashed the 9199 image I created back over to the console and probed the points. The good news is I did NOT receive the 0xAE general exception from the HV. The bad news is that I have received an undocumented POST code. Probing from POST7 to POST0, every single point had a roughly 1.2V reading (by rough +- 0.1V), hence when I assembled the bits into a byte, I got 1111 1111 i.e. 0xFF.

TEIR1plus2 TEIR1plus2 or anyone else viewing this thread, do you know the meaning of the 0xFF POST code?

Hopefully, that's a specific error rather than a general one so I don't need to go back to the POST sniffer to see the exact failure point, but yeah. Just to reiterate, I've got a Falcon RGH1 console, I CAN boot Xell and my Coolrunner stops glitching at an expected time AS IF the console was going to boot, but I get nothing on the screen. This suggests the glitch itself was successful, but something down the line in the boot process is causing an issue.

I should also add I know my probe method to be reliable - I'm grounding against the chassis. I tested this method on a working Zephyr which booted to the dashboard and got 0x79 i.e. LOAD_XAM, the last stage in the boot process.
 
Last edited:
TEIR1plus2

TEIR1plus2

VIP
VIP
Hidden Devils
Frame In Gold Programmer A Milli
Messages
510
Reaction score
224
Points
305
Sin$
0
that's a fatal error in the hypervisor. The possible hypervisor POST codes are as follows:
Code:
enum BLDR_POST_HV {
  BLDR_POST_HV_S_INIT_HYPERVISOR = 0x58,
  BLDR_POST_HV_S_INIT_SOC_MMIO = 0x59,
  BLDR_POST_HV_S_INIT_XEX_TRAINING = 0x5A,
  BLDR_POST_HV_S_INIT_KEYRING = 0x5B,
  BLDR_POST_HV_S_INIT_KEYS = 0x5C,
  BLDR_POST_HV_S_INIT_SOC_INT = 0x5E,
  BLDR_POST_HV_S_INIT_SOC_INT_COMPLETE = 0x5F,
  BLDR_POST_HV_E_FATAL = 0xFF
};

That error will happen during init of the hypervisor or during a syscall. This means something is wrong with hv patches. You could start adding patches to dump to uart at different points of the init process, that way you can narrow down where its failing.
 
Top Bottom
Login
Register