Tested this on X2 hardware. Just causes a frag. Board is a debug 1.1 basically.

In theory, how does the visor trick work when RAM is not yet initialised by Xcodes?

Yes, the visor overflow trick won't work since RAM is not initialized yet, so I have pursued another idea to bypass the proprietary X-code interpreter, which is pulling A20M# low at reset.

That idea is currently being implemented in my QPI fork of OpenXenium, which is using modern Winbond SPI flash in QPI mode, as a 1:1 bridge to the LPC bus, by using an FPGA instead of a very limited CPLD, with an added MOSFET to pull A20M# on the CPU low at reset.

Closing this PR as the trick will not work, and hardware initialization will be implemented this way (with possibly a coreboot or barebox port).

EDIT: This comment is only applicable to MCPX X3 southbridges & PR is missing 1BL initialization for X2 southbridges.

The visor overflow trick is not necessary for MCPX X2 southbridges, where there is no 1BL ROM, and behaves like a typical nForce chipset, and will just execute from the LPC bus (or primarily TSOP for Xbox). For MCPX X3 southbridges, the ROM is there & this PR won't be applicable (or will apply if A20M# is pulled low at reset via my OX QPI fork).

Just realizing that there is no reset vector code in Cromwell to do 1BL initialization & this PR is missing that, which #18 addresses, and why this PR in its current state did not work on @GXTX's X2 hardware.

Here's what the Cromwell image at the reset vector is currently & needs fixing:

$ objdump -DMintel -bbinary -mi386 --start-address=0x3fff0 cromwell.bin

cromwell.bin:     file format binary


Disassembly of section .data:

0003fff0 <.data+0x3fff0>:
   3fff0:	50                   	push   eax
   3fff1:	4c                   	dec    esp
   3fff2:	b3 c7                	mov    bl,0xc7
   3fff4:	e2 13                	loop   0x40009
   3fff6:	70 fc                	jo     0x3fff4
   3fff8:	32 55 29             	xor    dl,BYTE PTR [ebp+0x29]
   3fffb:	76 0c                	jbe    0x40009
   3fffd:	a8 ae                	test   al,0xae
   3ffff:	41                   	inc    ecx

This apparently needed some clarification & it's been a while since I've looked at this PR. It would probably be better for this PR to keep the X-codes for X3 southbridges, while having support for X2 (and possibly nForce) southbridges.

The above mentioned objdump is the end/top of the Cromwell image of an MD5 sum part of a 64 byte struct BiosIdentifier that is written by writeBiosIdentifier() in imagebld.c during build.

This will have to change to accommodate a jump from the reset vector to a page that is before the 512 byte 1BL ROM, to do 1BL initialization, pull A20M# high (if using my OX QPI fork), set protected mode, then do translated X-code initialization of RAM.

Works great on a 1.0 Retail (MCPX X3), 1.0 Debug (MCPX X2), and 1.2 Debug (MCPX X2).

cromwell_1024.zip

Hello, how can I remove this bios from an Aladdin chip and put another one.
I try it through CD and it doesn't recognize it and neither does DHCP.

I need to remove the Cromwell bios.

Thank you