Jump to content
OGXbox.com

Why did flashing a kernel file with XBlastOS break the XBOX?


calebTree
 Share

Recommended Posts

I grabbed a Kernel file from this page and I flashed it with XBlastOS.

Does the kernel have to match the original kernel? 

What is the kernel relative to the BIOS? Normally kernel and BIOS are two very different components of a computer. I shouldn't have been able to flash the TSOP with the kernel correct?

How are those kernels meant to be used?

I was looking for the default BIOS.

Thanks

 

Edited by calebTree
Link to comment
Share on other sites

  • calebTree changed the title to Why did flashing a kernel file with XBlastOS break the XBOX?

Did game disks update the kernel? I thought they just updated the dashboard. My understanding is that the kernel is basically the part of the OS that is closest to the hardware and thus has the least abstraction. In XBOX terms I would imagine the kernel is mostly the whole OS and then dashboards are simply on top of the kernel.

You're saying you believe XBlastOS could have flashed that kernel file to something other than the TSOP?

Yep, I had ind-BIOS working with 64MB RAM and at the time I inadvertantly didn't make the distinction between kernel and BIOS thinking I was going to flash that file and it was going to bring back stock BIOS.

Edited by calebTree
Link to comment
Share on other sites

The Xbox kernel is part of the Xbox BIOS, which resides in the TSOP packaged flash memory chip in 1.0-1.4, and in Xyclops chip in 1.6. In case of Xbox, you could even use the Kernel and BIOS terms interchangeably without annoying too many people.

The game discs most definitely were NOT capable of updating the kernel. That's not even physically possible because the write access is physically disabled by default.

  • Thanks 1
Link to comment
Share on other sites

On 1/21/2021 at 8:25 PM, calebTree said:

I grabbed a Kernel file from this page and I flashed it with XBlastOS.

Does the kernel have to match the original kernel? 

What is the kernel relative to the BIOS? Normally kernel and BIOS are two very different components of a computer. I shouldn't have been able to flash the TSOP with the kernel correct?

How are those kernels meant to be used?

I was looking for the default BIOS.

Thanks

 

What version Xbox do you have?

Which kernel/BIOS did you flash to the TSOP?  

In the xbox scene, kernel and BIOS are considered one in the same; however, they actually are not.  The BIOS's dot bin file contains a boot loader, 2BL (second boot loader) and a compressed kernel.

  • Thanks 1
Link to comment
Share on other sites

On 1/22/2021 at 1:53 AM, bolofski said:

my understanding was the kernel doesnt get written to the tsop, the kernel is somewhere between the bios and OS, game disks were capable of updating the kernel so it couldnt have been written to the tsop, what are you trying to achieve? a stock xbox?

The kernel is part of the BIOS's dot bin file (digiex's kernels are BIOSes).

The BIOS/kernel dot bin file contains a boot loader, 2BL (second Boot Loader) and a compressed Xbox kernel. 

The entire bios dot bin file is flashed to the TSOP. Either 1x the 256KB BIOS image for 1.2 to 1.4 or 4x the 256KB BIOS image (1MB in total) for v1.0/1.1 Xbox consoles.

  • Thanks 1
Link to comment
Share on other sites

If you wrote a BIOS version of 1.0.4627.X or lower to a 1.1-1.4 motherboard or a BIOS version of 1.0.4817.X or above to a 1.0 motherboard then the result would be a "coma console" because 1.0 and 1.1+ motherboards have a differing MCPX ROM and use a different encryption algorithm for decrypting 2BL into memory (1.1-1.4 boards also have an extra step in the bootchain)

All official retail Microsoft BIOS' are 256KB so if you wrote a 1MB BIOS image and it wrote at least 256KB of the image to flash then that's technically okay but if you wrote a 1.0 image to a 1.1-1.4 revision or vise-versa then 2BL can't be decrypted properly and that's why your console is 'bricked'. You can recover the console by installing a modchip and I believe you can recover the TSOP as well but I'm not the one to answer how to go about that

 

Quick rundown of critical failure states on the Xbox:

Coma console: An error in 1BL or fatal hardware failure (CPU, NB (imbedded in GPU), SB (MCPX), RAM, SMC, or TSOP, and anything in between connecting those chips.. so basically anything) - no code to be able to signify an error to a user

LED blinking: An error in 2BL (or FBL/2BL on 1.1+ revisions) or fatal hardware failure (RAM, GPU, or EEPROM) or something wrong with the kernel image - can blink LED's with code to write to SMC

Error screen: An error in kernel or something wrong with higher level buses, devices, software, or basically any chip on the board not behaving correctly when the console is in a fully initialized state

 

You're correct in saying BIOS' and kernels are usually separate things, the Xbox doesn't actually have a "BIOS" but that's what the modding scene labeled it as a long time ago - it's more so firmware. The Xbox "BIOS" is 2-3 separate blobs of code mushed together into a single chunk of data stuffed onto a flash chip (or ROM on 1.6)

BIOS = 2BL + kernel

or

BIOS = FBL + 2BL + kernel (in the case of 1.1+ revisions)

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

Awesome replies everyone, and exactly the answers to questions I have accumulated from browsing the vast XBOX mod scene content everywhere on the internet.

Apparently 1BL is the secret boot ROM that was discovered to exist on the MCPX (bunnie) before booting is handed off to 2BL which exists on the TSOP. Then, 1.1+ revisions introduced an additional security measure between 1BL and 2BL which is FBL.

Apparently the digiex files are 2BL software which include the compressed and encrypted kernel that also resides on the TSOP and which is decrypted with the help of the MCPX.

On 1/22/2021 at 2:40 AM, calebTree said:

Yep, I had ind-BIOS working with 64MB RAM and at the time I inadvertantly didn't make the distinction between kernel and BIOS thinking I was going to flash that file and it was going to bring back stock BIOS.

Correction above was that I had the 128MB RAM mod working before I flashed the file from the digiex forum.

On 1/23/2021 at 3:10 AM, KaosEngineer said:

What version Xbox do you have?

Which kernel/BIOS did you flash to the TSOP?  

In the xbox scene, kernel and BIOS are considered one in the same; however, they actually are not.  The BIOS's dot bin file contains a boot loader, 2BL (second boot loader) and a compressed kernel.

The XBOX I have in question here is a 1.0, 3944 original kernel until I flashed probably 5713 and broke it. Thanks @feudalnate and @KaosEngineer for consolidating and clarifying so much on the size of the .bin kernel/bios files and the ROM size differences across revisions.

I would like to get my OpenXenium mod chip working to recover from this but I haven't been able to since the bad flash and I am still investigating. I would have had iND-BIOS 5.003 (F only) running at the time from the HeXEn 2018 disk. Which was why I wanted to get stock BIOS back because shortly after using that BIOS for a minute I got a kernel panic, then the blubber intro got goofed and was over zoomed in, then also for some strange reason I couldn't copy the dashboard audio files to my HDD from Rocky5's Softmod Extras - I would only get empty folders.

Now at least I understand how the kernel/bios files are compatible or incompatible across mainboard revisions.

Here were the ohms Ω readings from black on D0 to red on each pin. The broken board had the TSOP write protection points R7D3 (top) and R7R4 (bottom) joined. It also had the OpenXenium chip hopefully installed correctly with a wire going from D0 to the mod chip's D0.

214152859_ScreenShot2021-01-28at12_25_54PM.thumb.png.3b808ebed8643ee5d9116065e5b0c6ed.png

 I don't know what this data means yet but at least it's consistent. Here is the % increase data from the broken board to the working board.

1101929227_ScreenShot2021-01-28at12_52_02PM.png.285f7e126f1ce4045e79ae389014893a.png

On 1/24/2021 at 1:16 AM, feudalnate said:

If you wrote a BIOS version of 1.0.4627.X or lower to a 1.1-1.4 motherboard or a BIOS version of 1.0.4817.X or above to a 1.0 motherboard then the result would be a "coma console" because 1.0 and 1.1+ motherboards have a differing MCPX ROM and use a different encryption algorithm for decrypting 2BL into memory (1.1-1.4 boards also have an extra step in the bootchain)

I don't think I have the "coma console". I have blinking lights frag exactly as described in this GitHub issue. My unit does have the identically described frag but as far as I can see it doesn't look like it is caused by OpenXenium in my scenario.

 

Edited by calebTree
readability
Link to comment
Share on other sites

Set your multimeter to 20 VDC or if it is a auto ranging then DC volt/VDC

Connect the black lead to ground of the Xbox power connector( black wires) or the metal shield.

The red probe should give around the same readings as this.

Don't worry if the top 2 pins read nothing

The D0 should read 0 volt and should read around 3 to 5 volt for 1/2 a second when you 1st turn on the Xbox then read 0 volt that's if the D0 is connected to the D0 on the main board

 

Open-Xenium-voltage-readings.jpg

 


SS Dave


Soft modding is like masturbating, It gets the job done but it's nothing like the real thing.

  • Thanks 1
Link to comment
Share on other sites

Great, yeah, yep, I have an issue on pin 5, RST. I already reflowed the solder twice on that pin with good Chip Quik flux to no avail. I'm just getting 0.19 v every time. I could reflow the solder on all the pins later but for all I know there is internal damage at this point too. I'm just getting closer I guess.

image.png.c19c93ec70eebd88a1580b8cf75e9fd5.png

PXL_20210129_091700452.jpg.06eeadd21c788725759c2b9e3c4b6dee.jpg

This was a board as you can see I learned some solder lessons on the hard way. Wouldn't it be nice if it got up and working again though.

14 hours ago, calebTree said:

Here were the ohms Ω readings from black on D0 to red on each pin. The broken board had the TSOP write protection points R7D3 (top) and R7R4 (bottom) joined. It also had the OpenXenium chip hopefully installed correctly with a wire going from D0 to the mod chip's D0.

I also want to be more specific that my data tables above were read from D0 (bottom) to the LPC pins (bottom).

Edited by calebTree
Link to comment
Share on other sites

There is a good chance there is a damaged trace under the pin header.

 

Pin 5 connects to the Q7R1 6 pin ic on the bottom of the board and I think that the rest control.

Now test from pin 5 on the bottom of the board to R7R5 one side of that resistor should test as 0 ohm and the other side of the resistor as 100ohm

 

Cheers

SS Dave


Soft modding is like masturbating, It gets the job done but it's nothing like the real thing.

 

 

  • Thanks 1
Link to comment
Share on other sites

Right, I get 101.3 ohms on one side and 1.3 ohms on the other side of R7R5.

Good to know pin 5 connects to Q7R1. I'll have to probe around that and see what I can learn.

Q7R1.jpg.9eb5e26f6b3449dad17f40e78ec5ee6d.jpg

Okay, so I have continuity between pin 5 and all the legs of Q7R1 other than the circled leg pictured above and I should which I know because I am comparing to a known working board. In the image above Q7R1 and C8R2 are missing because they fell off before I took that picture but I have since put them back on. Apparently I might have to work on Q7R1 though.

Edited by calebTree
Link to comment
Share on other sites

Hopefully these pics will help.

 

[url=https://postimg.cc/K49BmW8c][img]https://i.postimg.cc/QxDbJGL7/xbox-1-1-top-clean.jpg[/img][/url]

 

[url=https://postimg.cc/fkkkfRMZ][img]https://i.postimg.cc/fkkkfRMZ/xbox-1-1-bottom-clean.jpg[/img][/url]

 

 

Cheers

SS Dave


Soft modding is like masturbating, It gets the job done but it's nothing like the real thing.

 

 

 

 

 

 

  • Thanks 1
Link to comment
Share on other sites

28 minutes ago, calebTree said:

Okay, so I have continuity between pin 5 and all the legs of Q7R1

You should not have continuity on any pins but this one (Black/white lighting bolt)

And when you refit the IC ensure the dot in the IC is toward the yellow/white arrow

 

Q7R1.jpg.9eb5e26f6b3449dad17f40e78ec5ee6d.jpg.f45364649cd86a3ba289e2bebfdeafec.jpg

 

Cheers

SS Dave


Soft modding is like masturbating, It gets the job done but it's nothing like the real thing.

  • Thanks 1
Link to comment
Share on other sites

Yeah, I don't have a buzzer type continuity multimeter so for sure on my working board like you say the black lightning is 0.0 ohms and the other pins have resistance. There's also the question of black lead on pin and red on component to test or vice versa which I haven't figured out yet. 

Link to comment
Share on other sites

When you where testing the pins of the IC was it on the board?

 

7 minutes ago, calebTree said:

There's also the question of black lead on pin and red on component to test or vice versa which I haven't figured out yet. 

For the tests you are doing at the moment it makes no difference.

 

Cheers

SS Dave


Soft modding is like masturbating, It gets the job done but it's nothing like the real thing.

  • Thanks 1
Link to comment
Share on other sites

I am really surprised at how quickly the culprit could be tracked down with some strategic use of the multimeter. Honestly, the voltage test was the next thing I was going to do when I was ready to start probing the xbox with it plugged into the wall.

final.thumb.jpg.b6ec888e43dbb15bb28f36f2fe235d4a.jpg

10 hours ago, SS_Dave said:

When you where testing the pins of the IC was it on the board?

Yes, the IC was on the board. Now, I decided to remove it again though and check and there is no change.

When I'm talking about continuity I have to use the resistance setting on my multimeter so when I say I have continuity I mean I get a (significantly low) ohms reading.

I don't get continuity between GND and A or B. Yet, I do on all the other pads of the IC and I do on the working board.

I do get continuity between A (the via) and B (the IC pad).

I should also get continuity between B and all the other pads of the IC but I don't.

Edited by calebTree
Link to comment
Share on other sites

I hypothesis there must be damage to an internal layer of the PCB from when I was impatiently trying to install the pin header using a heat gun because I didn't know how to use solder wick correctly. Eventually I learned from this video how to use solder wick correctly: https://youtu.be/xty1G5UBYb0

In the "Soldering Techniques" section of Appendix B in "Hacking the XBOX" by Andrew "bunnie" Huang, Huang does talk about removing components on a budget with a heat gun. In my experience I don't recommend it (and it's obvious from the damage) because for example my heat gun specs were: Low - 50 - 350 C, High - 200 - 500 C, Air Flow: 450L/min. As soon as a SMD would come loose it would just blow away. Compared to a proper hot air rework station which is much more gentile: 100 - 480 C, 20 - 130L/min.

I am not aware of an economical way to repair damage to an internal layer of a PCB. I had fun though and learned a ton! Unless anyone has any other ideas I will have to add this board to my sacrificial pile.

For those playing at home this thread was where I started this question: Open Xenium Install Question (damaged board) - Modchips - OGXbox.com

 

Edited by calebTree
Link to comment
Share on other sites

  • 2 weeks later...
On 1/22/2021 at 1:53 AM, bolofski said:

my understanding was the kernel doesnt get written to the tsop, the kernel is somewhere between the bios and OS, game disks were capable of updating the kernel so it couldnt have been written to the tsop, what are you trying to achieve? a stock xbox?

 

On 1/22/2021 at 2:40 AM, calebTree said:

Did game disks update the kernel? I thought they just updated the dashboard. My understanding is that the kernel is basically the part of the OS that is closest to the hardware and thus has the least abstraction. In XBOX terms I would imagine the kernel is mostly the whole OS and then dashboards are simply on top of the kernel.

 

On 1/22/2021 at 5:45 AM, lapa988 said:

The Xbox kernel is part of the Xbox BIOS, which resides in the TSOP packaged flash memory chip in 1.0-1.4, and in Xyclops chip in 1.6. In case of Xbox, you could even use the Kernel and BIOS terms interchangeably without annoying too many people.

The game discs most definitely were NOT capable of updating the kernel. That's not even physically possible because the write access is physically disabled by default.

 

Apparently the NDURE exploit is able to "patch" the kernel. See Rocky5 "Softmodding Tool" explanation of NKPatcher Settings: https://github.com/Rocky5/Xbox-Softmodding-Tool#nkpatcher-settings

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.