Print

[rizza]

QUOTE (ldots @ Jun 28 2004, 10:21 PM)

The reason why I find this interresting is that if you remove this code PBL doesn't work anymore. Knowing more about how PBL works now I have a feeling this is what trickers the kernel to go into debug mode (or what we should call it) which might be needed for enabling the new bios. Remember that PBL enables the bios that is being loaded in memory by doing a QuickReboot. Well, I will look a bit more at the code. More tests awaits

You guys realize that you are largely recreating PBL 1.3, right?  It didn't have all the USB BIOS selection stuff etc.  Otherwise, it is largely the same as far as the actual bios loading goes.  I'm not sure why 1.4.1 does the Quick Reboot because it isn't necessary (at least on my Xbox).  1.3 certainly doesn't do it.  What's nice about 1.3 is that it includes all the source required to compile it--no need to use free-xdk.  For this reason, after stripping eerything out but the config parsing and bios loading, you can get a working PBL of only 14KB (probably less with further optimization).  Also, the stripped PBL 1.3 works fine w/o the "VideoStandard" code.

[Chicken Scratch Boy]

rizza, you cant use newer bioses with 1.3 at least i think....

[ldots]

Either way I will have a look at the code. Maybe merge some of the newer features of 1.4.1 with a super fast, no-animation version based on 1.3.

[jonathan2007]

QUOTE (ldots @ Jun 29 2004, 02:17 AM)

Either way I will have a look at the code. Maybe merge some of the newer features of 1.4.1 with a super fast, no-animation version based on 1.3.

now that would be awesome.  

[Tomilius]

So has anyone tried the new one yet?

And if 1.3.5i applies to QuickReboot not happening, I'll have you know that its biosloader.c is line-for-line identical to the one included in the 1.4.1 source... I wonder where I can find the source for version 1.3?

[dabbage]

tomilius - its included in the "signed phoenix bios loader" package in the usual places.

[Tomilius]

It's not that important to most people. The fix will remain in future versions, of course. All it is is moving the line "wait_ms(entry->timeout);" in biosloader.c up above "fb_clear();", lol.

---

I think the rest is out of my hands. I hope someone is able to get free-xdk to support S-VIDEO, etc. ... then I'll do a recompile with that support and call it v1.3. Or something. But the person who fixes free-xdk will of course get most of the credit... or the person who does that can just recompile my Source themselves or... whatever, lol, I'm done talking.

[rizza]

QUOTE (Tomilius @ Jun 29 2004, 02:50 AM)

So if it performs a QuickReboot, does that mean the ASM code at the end is the code for a QuickReboot? I tried replacing it with a LaunchXBE instead, and it loads EvoX fine, but no signs of the BIOS having actually loaded are shown (trying to load UnleashX causes an error 21 :| I think I was unable to get that to sign with xbedump.)

The ASM code at the end is where PBL jumps into the new BIOS/kernel in memory.  Nothing happens in PBL after that AFAICT.  The new BIOS immediately loads, and PBL is out of the picture completely.  Thus, execution seemingly never even gets to the second "HalReturnToFirmware(RebootQuick)," so I'm not sure why it is in there.  It isn't necessary AFAICT.

As far as PBL 1.3 not loading newer BIOSes, that is actually correct.  After a lot of debugging, I found out why.  There are two problem areas in the 1.3 code that are commented out in the 1.3.5i (and higher) code (presumably for the very reason that this code causes newer BIOSes to fail to load):
1) The setLED call in boot()
2) The tray state checking/branching code in boot()

Both of those two code areas read/write from the SMBus, and apparently this causes problems.  Once these are commented out, 1.3 loads newer BIOSes just fine.  It would have been nice of whomever commented these two parts out in 1.3.5i to have noted this problem...

NOTE: Contrary to what I wrote earlier, the "VideoStandard" code ldots pointed out IS necessary to load newer BIOSes (but not older ones, which is strange).  The reason for this is unknown.

[Tomilius]

QUOTE (rizza @ Jun 29 2004, 05:29 AM)

The ASM code at the end is where PBL jumps into the new BIOS/kernel in memory.  Nothing happens in PBL after that AFAICT.  The new BIOS immediately loads, and PBL is out of the picture completely.  Thus, execution seemingly never even gets to the second "HalReturnToFirmware(RebootQuick)," so I'm not sure why it is in there.  It isn't necessary AFAICT. As far as PBL 1.3 not loading newer BIOSes, that is actually correct.  After a lot of debugging, I found out why.  There are two problem areas in the 1.3 code that are commented out in the 1.3.5i (and higher) code (presumably for the very reason that this code causes newer BIOSes to fail to load): 1) The setLED call in boot() 2) The tray state checking/branching code in boot() Both of those two code areas read/write from the SMBus, and apparently this causes problems.  Once these are commented out, 1.3 loads newer BIOSes just fine.  It would have been nice of whomever commented these two parts out in 1.3.5i to have noted this problem... NOTE: Contrary to what I wrote earlier, the "VideoStandard" code ldots pointed out IS necessary to load newer BIOSes (but not older ones, which is strange).  The reason for this is unknown.

What

QUOTE

second "HalReturnToFirmware(RebootQuick),"

are you talking about?

Oh, you mean the one after the mainthread? Of course it never gets there. Like you said, execution never gets that far (that's what I figured.) So there's no reason for it to be there since not only is it unnecessary but it never does a thing.

So PBL 1.3 never had issues with S-VIDEO? Then it would be a good idea to just combine them. Or wait - what is the benefit of doing that again? It makes absolutely no difference whether the QuickReboot is there or not... does it? So why ever even mention that? Hehe. So again, what's so good about 1.3, and what would be beneficial about combining it with 1.4.1?

[dabbage]

QUOTE (Tomilius @ Jun 29 2004, 03:21 AM)

So has anyone tried the new one yet? And if 1.3.5i applies to QuickReboot not happening, I'll have you know that its biosloader.c is line-for-line identical to the one included in the 1.4.1 source... I wonder where I can find the source for version 1.3?

Oops, sorry.  You can (really) get all the older pbl's with source here:

http://www.maxconsol...x&categoryid=26

[dabbage]

[PedrosPad]

QUOTE (ldots @ Jun 28 2004, 10:21 PM)

An interresting thing is the code in the ParseConfig routine. CODE      for(i = 0; i < 4; i++) {              VideoStandard = I2CTransmitByteGetReturn(0x54, 0x58 + i);      }

Don't waste any time on this....
..but have you seen been able to see the contents of VideoStandard[] array after this loop?  It's just that retrieving 4 consecutive bytes is just enough to get "NTSC", or "PAL\0" - just an observation.

[Dan Wysocki]

QUOTE (Tomilius @ Jun 28 2004, 11:16 PM)

Could you be more specific? "The screen rolls?" Not sure what you mean by the Flubber animation, lol. Also, please post your boot.cfg (without any RC4 keys or EEPRom keys of course). By the way, this reminds me A LOT of ROE not being fixed in nkpatcher for me but for other people it was. Hehe.

Im at skool at the moment so i cant post by config, but, when i say the screen rools, i mean the image on the screen "rolls" up the screen and then back on the bottom again..dunno if that made any sense...
as for the flubber animation, i mean the bit that appears as soon as you hit the on button on your xbox (that green, flubber like blob)
it only ever does that with your pbl...ill post my boot.cfg as soon as i get home..

[ldots]

QUOTE (PedrosPad @ Jun 29 2004, 09:22 AM)

It's just that retrieving 4 consecutive bytes is just enough to get "NTSC", or "PAL\0" - just an observation.

Yup, my thoughts too.

It must have some significance   for PBL though. I dont see this VideoStandard array being used anywhere, but yet PBL does not work if these lines are commented out.

I also remember Yoshihiro talking about that manipulating the eeprom to force the kernel into "debug" mode was nessecary for PBL to work. For a brief moment he thought he had PBL working on kernel 5530 after some eeprom patching.

I just guessing though

Just stripped down PBL 1.3 myself. Loads really fast! But yeah, I guess its pretty much identical to the stripped 1.4.1. Booting Vga there is no screen corruption - would be nice to add Focus support to get rid of a very brief screen flicker.

[PedrosPad]

QUOTE (ldots @ Jun 29 2004, 09:42 AM)

It must have some significance   for PBL though. I dont see this VideoStandard array being used anywhere, but yet PBL does not work if these lines are commented out.

Could be a timing thing, or the port IO initializes something.  Rather then zapping the whole lines, try

CODE

for(i = 0; i < 4; i++) {    I2CTransmitByteGetReturn(0x54, 0x58 + i); }

to see if it's the I2CTransmitByteGetReturn() that's got to happen, or the population of  VideoStandard[] array that's important.

QUOTE (dabbage @ Jun 29 2004, 09:43 AM)

VideoStandard[] is: 0x00 0x01 0x40 0x00 here i found i only have to read the first of the four for it to boot.  file that under useless info

That answers that

Fragments from the latest CVS Cromwell sources:
BootEEPROM.h:

CODE

//Structure that holds contents of 256 byte EEPROM image.. typedef struct _EEPROMDATA {   BYTE  VideoStandard[4];     // 0x58 - 0x5B  ** 0x00014000 = NTSC, 0x00038000 = PAL

BootEEPROM.c:

CODE

void BootEepromReadEntireEEPROM() {    int i;    BYTE *pb=(BYTE *)&eeprom;    bprintf("Starting EEPROM read\n");        for(i = 0; i < 256; i++) {  *pb++ = I2CTransmitByteGetReturn(0x54, i); //  bprintf("%d\n", i);    }     }

So it seems the for/next loop reads bytes 0x58, 0x59, 0x5A, 0x5B from the EEPROM.
And in VideoInitialization.c:

CODE

xbox_tv_encoding DetectVideoStd(void) {    xbox_tv_encoding videoStd;    BYTE b=I2CTransmitByteGetReturn(0x54, 0x5A); // the eeprom defines the TV standard for the box    if(b == 0x40) {  videoStd = TV_ENC_NTSC;    } else {  videoStd = TV_ENC_PALBDGHI;    }    return videoStd; }