Jump to content
OGXbox.com

Research into the Xbox EEPROM data


feudalnate
 Share

Recommended Posts

For the last year or two I've been working on reversing some of the data structures that have been left unresearched or incomplete by the old scene, not to such a hardcore degree as I would honestly like but off and on when I have the time. This spans from what most people have seen me put out like the Xbox LIVE account stuff but I also have an interest in FATX16/32 structuring, the various configuration/datastore sectors at the beginning of the Xbox hard drive, the 1BL/FBL/2BL/BIOS image structures and data packing, XBE header/certificate data, security, and structuring, and the EEPROM data and structuring - the fundamental data types that make up the Xbox

Today I completed the EEPROM data structure - well I say "completed" but there are still some things like flags, bitpacking, and a single unlabeled 16bit value to truly finish up all the info on the data handling side of things - however, structurally I have mapped out all the EEPROM data including the notorious hardware section as well as reversing the XConfigChecksum into something much more legible, portable, and simply more correct than what's been sitting on the XboxLinux/XboxDev wiki's for the last decade and a half 

I didn't really feel posting something like this on Reddit would be the way to go, the constant Twitter-feed like nature of threads just buries information and I have always preferred forums for their organization - and besides, forums are where I started in modding and forums are what I ran/helped run for many years of my modding life

Anyway to my point, if you're interested in the structure and/or (partial for now) handling of EEPROM data then I've posted all the info on my GitHub project. This information can be used to parse, edit, or build an EEPROM image from scratch for any revision of the Xbox (including 1.6 and 1.6b models). I'll likely make a tool for people to create/edit EEPROM images at some point but I've got a couple Xbox projects I've been working on for a while and would like to finish at least one of those before starting another and I'll stuff all this structuring information into a table on the project page soon or maybe edit the XboxDev wiki so it's easier for non-programming people to view and understand at a glance

Thanks for reading (also, posting this in the general forum wasn't my first choice but this doesn't really fit into the topic of homebrew - it's more so R&D)

 

 

This paragraph has nothing to do with the subject of my post but I just wanted to say something personal here. I post this kind of information and put out these various tools and answer these questions that most people don't have an answer to for the sole purpose of bettering or further educating and simply just passing on information I know to the few left in original Xbox scene and even though I might come off as such it's never really been an ego or "clout" thing for me with the original Xbox, I've owned an original Xbox since 2001 and it's purely a passion thing. All I'm really after with this hobby of research and modding of the Xbox is to leave the scene with correct information or at least as correct as I'm able to comprehend and express to others, which I'm sure the old members of the early scene tried to do as well. The reason the original Xbox still lives on is because of sites like this and the handful of people that still hold onto their interest of the original Xbox or their passion of tinkering. Some of you may know my username and others may not, I've seen people mention me as this sort of Xbox "guru" or "expert" and I don't know if I come across as such but I can say, there are many things I don't know, many things I feel I'll never know, and a lot of times I feel like I barely know anything but I know objectively this isn't entirely true because there's a lot I know about the Xbox (and Xbox 360 for that matter) and yet it doesn't stop me from feeling dumb much of the time. Everything I know about computers, the Xbox/Xbox 360, data, structuring, programming, etc. is all self-taught and if you want to learn the type of stuff I know then you absolutely can teach yourself these things and it doesn't necessarily need to be on the software side of things, if you want to know hardware then you can teach yourself that as well - push yourself to learn, you are your best teacher. If you're part of the Xbox scene, whether you're a complete noob or have been around forever, whether we've had good/bad interactions in the past or maybe in the future, know that I appreciate you regardless of your knowledge or "status" and know that I hold no negative feelings towards anyone left in this scene and I probably never will. Not entirely sure why I just wrote this rant but hopefully no one minds, I'm just glad I'm not alone in this hobby of playing around with a 20 year old outdated machine

  • Like 3
  • Thanks 1
Link to comment
Share on other sites

For those that are interested I have written some documentation on the EEPROM. There's still a bit of research to do but for the most part it's complete and as far I can tell, is the most robust documentation on the subject. Let me know if you spot any mistakes/misinformation or something I missed

https://github.com/feudalnate/Original-Xbox-Data-Structures/blob/master/EEPROM/README.md

I would have edited this into my original post but this usergroup doesn't have edit permissions

Link to comment
Share on other sites

1 hour ago, feudalnate said:

For those that are interested I have written some documentation on the EEPROM. There's still a bit of research to do but for the most part it's complete and as far I can tell, is the most robust documentation on the subject. Let me know if you spot any mistakes/misinformation or something I missed

https://github.com/feudalnate/Original-Xbox-Data-Structures/blob/master/EEPROM/README.md

I would have edited this into my original post but this usergroup doesn't have edit permissions

Great writeup... for the values "extended slow", "slow", "typical", etc... I wonder if those could be due to the memory test on bootup. 
Since Samsung sold MS some shit memory chips, the Xbox had to test their stability on boot at various speeds trying to find the lowest common denominator of the 4 memory chips. This is why some Xbox's seem faster than others in spite of them having the same cpu and gpu. 
So I suppose those addresses could be various memory clocks that the Xbox can set on the fly. 
I wouldn't think you'd need all of the addresses if it were just making a note of which one was stable as that could be a single address and value. 

This is obviously all speculation and could be completely wrong. Just thought I'd offer it up. 

Link to comment
Share on other sites

35 minutes ago, OGXbox Admin said:

Great writeup... for the values "extended slow", "slow", "typical", etc... I wonder if those could be due to the memory test on bootup. 
Since Samsung sold MS some shit memory chips, the Xbox had to test their stability on boot at various speeds trying to find the lowest common denominator of the 4 memory chips. This is why some Xbox's seem faster than others in spite of them having the same cpu and gpu. 
So I suppose those addresses could be various memory clocks that the Xbox can set on the fly. 
I wouldn't think you'd need all of the addresses if it were just making a note of which one was stable as that could be a single address and value. 

This is obviously all speculation and could be completely wrong. Just thought I'd offer it up. 

For the older revisions of 2BL there are similar tables of values that are stored and read directly from the BIOS image, sent to the NB/GPU to do calibration and is immediately followed by the memory test. I don't think you're far off on your guess, it's just the strange thing is that the table was moved into the EEPROM instead when older revision BIOS images have a specific table for Samsung memory and another for Micron memory then just does a check beforehand to see what type of memory the system has and uses the appropriate one but in the case of 1.6 and 1.6B models they shoved the table into the EEPROM instead

It's like they didn't know if they could get different memory chips in advance when releasing 1.6 revisions? It would have been trivial for them to just update the table in the BIOS and recompile it or just have multiple tables stored for different types of memory like the earlier revisions. Not sure, maybe they manufactured all the 1.6 boards at the same time with the standard 1.6 BIOS pre-flashed to the ROM in Xyclops chip and then just used whatever memory they had on hand then updated the hardware section of the EEPROM accordingly? I stated in my write up that perhaps it had something to do with the model of GPU they used and that might be true too, it's difficult to say. The 1.6 revision boards have always seemed a bit hacky and probably why it has various issues with even retail software

I can confidently say that those values in the hardware section of the EEPROM are for memory but I have no idea how those values work when they're passed to the GPU BIOS

Edited by feudalnate
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

Board Life Status


Board startup date: April 23, 2017 12:45:48
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.