Extremely Intel X48

If it is anything like the bonetrail,it will be a board to skip.Bios limited,buggy bios, 500fsb max,1521 made it slightly more intresting.Alot of play time in need to oc the bonetrail.Think i lost all my hair with that mobo.Good luck.

ebab592e.jpg
 
Can we stop using the fricking word "extreme"? I am tired of hearing it. Doesn't any manufacturer have a damn thesaurus?
 
Well, the X48 block diagram did show 4 lanes of PCIe bonded into a 3rd mechanical x16 slot - I guess that's the black x16 slot?

xFire + RAID? ...but then, who needs host RAID when you get ICH10 on these boards?
 
I don't see this for sale..... anywhere.


How would anyone have it? (other than engineering samples?)
 
I don't see this for sale..... anywhere.


How would anyone have it? (other than engineering samples?)

Clubt IT - Out of Stock - 299.99
Shopblt - Out of Stock - 276.01
ZZF - Out of Stock - 299.00

ETA 4/14/08
 
Clubt IT - Out of Stock
Shopblt - Out of Stock

ETA 4/14/08

figures, the 2 places i forgot to check.

Oh well.

Hopefully newegg will throw it up soon. $300?!!?!? will it gimmie a hand job during the install? ;)
 
Well, the X48 block diagram did show 4 lanes of PCIe bonded into a 3rd mechanical x16 slot - I guess that's the black x16 slot?

xFire + RAID? ...but then, who needs host RAID when you get ICH10 on these boards?

All the X48 boards I've seen still use ICH9R. Not sure what happened to ICH10.
 
Oops - this is ICH9. I actually looked at the PDF this time. Though from the tests I've seen around the web, ICH9 is no slouch.

I definitely would not bother with an addin card for RAID 0 or 1, but I think for RAID 5 its still a wise choice.
 
Snagged the DX38BT and a E8400 at the start of feb in a bundle deal for $399 cdn, couldn't pass that up. Had the E8400 up to 4 easily to check it out, remained at 3.6 daily over a month now with no problems. Bios could use improvements with options, but I've had no problems really reaching the goals I wanted with it and have no complaints really. Plopped a X3350 in it yesturday and had that up to 3.6 on this, passed 4 hours before I stopped it to game heh.

The DX48BT2 and DX38BT apparently will also share the same bios from what I have been reading.
 
Well, I'm specially interested in the X48's thermals. With that alu heatsink, I'd bet it will get really hot.
The SATA ports placement is interesting, I have to admit.
 
I am eagerly awaiting this dropping, so I can replace my X3210+BA2 with an Q9450+BT2.

Gonna wait for the prices to come down on the mobo (or a sweet deal, like my $175 BA2).
 
I'm really liking the new enthusiast logo, this board looks like a potential winner at the moment...

except for price ATM
 
This Board + 9800gx2 = -2 two sata ports :(

Well, yes. But there are hundreds of other videocards with a single PCB, which can be watercooled. That way you would end up not loosing any SATA ports.

Anyway, I said the placement was interesting, not good. :p
 
From the intel tech doc:
If you are using DDR3 1600 MHz DIMMs, it is recommentded [sic] that you only
populate two of the four DIMM slots, specifically one slot in each channel. It is
recommended that you populate slot 1 of each channel (black connectors).
The maximum system memory for DDR3 1600 is 2 GB using 1 Gbit technology
memory in a 1R x 8 configuration (single-sided modules).

:rolleyes:
 
Horribly crowded around the socket on this thing. Don't know what they were thinking. There will be clearance issues with a number of the big popular heatsinks unless my eyes deceive me.
 
It's not that cramped. It's a minor change from the BadAxe, and no change form the DX38BT.

While that does suck about the 2GB 1600 max, it's not uncommon when using the bleeding edge to have OEMs set some conservative specs.
 
I agree. These northbridges (even X48) are suprising me with this limitation, on either speed or ability to drive several GB. What gives? Why not make the MCH beefy enough to run 8GB at high speeds and not catch fire or cause stability problems? Is it the vrm? Is it the DDR?
 
From the intel tech doc:


:rolleyes:

Are you sure this is correct? Flipping through the manual now online I saw:

For 1600 MHz memory, only two DIMMs are supported for a maximum of 4 GB utilizing 1 Gb memory technology. DIMMs should be configured as a matched pair equal in speed and size in DIMM 0 and DIMM 1 of channel B.

Four DIMM sockets designed to support up to 8GB of DDR3 1333/1066/800 MHz memory -- all delivering greater performance.
 
I had 2x2GB running at 1600 7-7-7 1.7v in my DX38BT, and I'm sure I can get the 8GB I have in there now (Currently at 1333 9-9-9 1.7v) running at 1600 today.

What they say and what it can do are usually two very different things :)
 
Where's the review?:rolleyes:

Sorry, we don't get them completed in 12 hours like some other sites. If you are looking for "first" or early mobo reviews, HardOCP is not your spot. We stopped that shit years ago when all the "early" boards were not reprsentative of the motherboards our readers were buying.

I am not even through stability testing yet. Finally got an app crash at somewhere around 111 hours at 43C ambient.
 
Yes, this is correct.

From the intel tech doc:
If you are using DDR3 1600 MHz DIMMs, it is recommentded [sic] that you only
populate two of the four DIMM slots, specifically one slot in each channel. It is
recommended that you populate slot 1 of each channel (black connectors).
The maximum system memory for DDR3 1600 is 2 GB using 1 Gbit technology
memory in a 1R x 8 configuration (single-sided modules).

This is hardly limited to Intel's chipsets either. We are seeing this with ALL chipsets for the the Core 2 pretty much as well as NVIDIA's. We have mentioned this repeatedly over the last 6 months in various reviews and such. Don't think you are going to go 4 up and OC the hell out of the ram the way you can OC two sticks. And then make sure they are in the DDR set of slots furtherest from the CPU.
 
Are you sure this is correct? Flipping through the manual now online I saw:
Yes, as Kyle said it is correct. Look here on page 16.

This is hardly limited to Intel's chipsets either. We are seeing this with ALL chipsets for the the Core 2 pretty much as well as NVIDIA's. We have mentioned this repeatedly over the last 6 months in various reviews and such. Don't think you are going to go 4 up and OC the hell out of the ram the way you can OC two sticks. And then make sure they are in the DDR set of slots furtherest from the CPU.
This was the point of my complaint. I don't understand why we aren't seeing better engineering for MCH on these high-priced enthusiast boards. :rolleyes:
 
It's been 10 days now ; where's the review? Could you explain what the UEFI boot option is?
 
Yes, as Kyle said it is correct. Look here on page 16.


This was the point of my complaint. I don't understand why we aren't seeing better engineering for MCH on these high-priced enthusiast boards. :rolleyes:

Well, this is sort of an interesting point of contention. Intel will tell you that if you produced sticks of DDR3 that ran at JEDEC specs (which none do above 1333 TMK) that those parts would work. You have to remember here, we are overclocking the shit out of these sticks of RAM, way beyond current specs. I don't like it, but it is hard to point the finger only at Intel.
 
http://www.microsoft.com/whdc/system/platform/firmware/Efibrief.mspx

BIOS as PC Firmware
Each PC usually comes preloaded with firmware and, until recently, that was usually in the form of BIOS, which was first designed in the late 1970s. BIOS firmware has been through numerous changes to accommodate the modern-day needs of complex platforms. BIOS design was not governed by any standards other than commonly followed conventions, and BIOS vendors have worked to address the special needs of specific hardware vendors. Firmware usually resides on a limited-size EEPROM or flash memory (~1 MB). The size limitation is due to the costs of parts and maintenance. BIOS interfaces are used to start the Windows load process. BIOS is not used at OS runtime, with the exception that video BIOS support might be emulated.

Top of page
EFI as PC Firmware
EFI is the next-generation firmware model, set to replace the legacy BIOS in the coming decade. EFI serves as the interface between hardware platform and the operating system, providing information about the platform that is necessary for the operating system to boot. Although EFI is primarily used to boot the system, there is also some limited run-time support. For example, EFI provides run-time functions for manipulating EFI variables (used mainly for boot management), system time management, system reset, and so on.

EFI was initially developed by Intel Corporation and published in the EFI 1.0 specification. EFI has been used as the only supported firmware on Intel Itanium-based systems. Microsoft Windows Server 2003 was one of the first operating systems to support this interface on Itanium systems.

In 2005, Intel and Microsoft were among the founding members of the Unified EFI Forum. Other founding members of the forum include AMD, American Megatrends, Dell, Hewlett Packard, IBM, Insyde, and Phoenix Technologies.

Using the EFI 1.10 specification as the starting point, the forum began to develop, manage, and promote the Unified Extended Firmware Interface (UEFI) specification with the goal to bring UEFI to mainstream systems that have traditionally used a BIOS to boot. On January 31, 2006, the UEFI 2.0 specification from UEFI Forum was released.

The UEFI committee decided that UEFI firmware and the operating system must match bit-wise; that is, the maximum number of address bits used by the operating system must match the maximum number of address bits used by firmware. For example, 32-bit UEFI implementations have the ability to boot 32-bit operating systems, but not 64-bit operating systems. Likewise, a 64-bit UEFI firmware implementation has the ability to natively boot a 64-bit operating system, but does not support natively booting a 32-bit operating system. This restriction was reached for technical reasons related to runtime UEFI support, The UEFI specification also allows firmware vendors to add flexible support for booting operating systems that are designed to boot on traditional BIOS. For this, the UEFI vendor will integrate a firmware interface layer that performs the compatibility functionality while presenting the BIOS-type interface to an operating system that expects BIOS-type interfaces to boot.

Thus, any UEFI implementation can be written to provide boot support for native 32-bit, native 64-bit, and legacy BIOS-based operating systems. However, supporting all three of these options requires a very large firmware image which would not fit on a traditional PROM, adding to the cost of the bill of materials (BOM). This also adds to the validation costs for a platform, which in turn adds to the non-recoverable engineering (NRE) cost for the system manufacturer. However, it is practical to support both a native UEFI firmware implementation along with the BIOS firmware interface layer.

Microsoft expects that most UEFI platforms in the near future will choose native 64 bit support along with a BIOS compatibility module so that these platforms can run earlier versions of Windows that support boot only through a BIOS. Nearly all new processors in the Windows Vista timeframe will be 64-bit capable. Microsoft would like to use the advent of mainstream 64-bit computing as a transition point to enable a move toward EFI boot. Although a platform vendor could choose to have UEFI 32-bit support, this has a short life and diminishing returns. In the near future, OEMs won't need large, multipurpose firmware images.

Top of page
Evaluating BIOS vs. UEFI Support
UEFI is a technically superior solution to use for boot compared to BIOS. UEFI is well-specified and is a testable interface that will improve system compatibility and reliability. Architecturally, UEFI allows the transition away from real-mode 16-bit code that is common in BIOS. Its agility will improve time to market for platforms and will allow new scenarios to be developed in future release of Windows.

However, because BIOS boot is ingrained into all existing x86 and x64 deployments, Microsoft will continue to support BIOS-based boot for the foreseeable future. If UEFI becomes a well-established standard for booting systems, then Microsoft might consider a gradual transition away from BIOS-based boot support. It is likely that this transition would initially take the form of implementing only some features on UEFI systems.

Top of page
EFI, UEFI Support, and Windows Vista
Windows 2003 Server supports EFI 1.10 on Intel Itanium platforms. Microsoft Windows Server 2008 supports EFI 1.10 on Intel Itanium platforms, and also introduces support for native UEFI boot on x64 64-bit platforms. Although the initial release of Windows Vista will not include UEFI x64 64-bit support, a subsequent Windows Vista release will support UEFI.

Given the advent of mainstream 64-bit computing and the platform costs previously discussed, Microsoft determined that vendors would not have any interest in producing native UEFI 32-bit firmware. Microsoft has therefore chosen to not ship support for 32-bit UEFI implementations.

For Microsoft, support for UEFI means rigorous testing on a heterogeneous mix of UEFI implementations on a wide range of hardware platforms. As of mid-2006, no firmware vendor has yet provided production-ready UEFI implementations.

The inability to perform wide testing on multiple implementations creates a risk-adequate testing must be done before operating system support can be released. This risk has driven the decision to enable UEFI support with Windows Server 2008. By that time, it is expected that sufficient production-quality UEFI implementations will be available so Microsoft will be able to work with hardware vendors to test a wide range of platforms.

Microsoft is working closely with the Unified EFI Forum and industry partners to ensure that it can provide a high-quality, standards-based UEFI solutions. Microsoft has demonstrated Windows support for native UEFI boot at industry events such as Windows Hardware Engineering Conference (WinHEC). As part of this continuing effort, Microsoft is also making "technology preview" code for UEFI boot support available in the Windows Vista Beta 2 release. This technology preview allows partners to test their UEFI implementations to make production-ready samples available for Microsoft for testing support in Windows. The technology preview code will be removed for Windows Vista release candidates (RC) and final release to manufacturing. However, support for well-tested UEFI will be made available in a future update to Windows Vista. The supporting code will be present for Windows Server 2008 Beta 3 and Windows Server 2008 release to manufacturing.

To help smooth the transition from BIOS boot to UEFI boot, differences between UEFI and BIOS environments are abstracted from the end user wherever possible. Once the OS is fully functional, it shields the user from underlying firmware differences. For example, a new boot configuration data (BCD) store was designed for Windows to help abstract these differences and to enable easier deployment of BIOS and UEFI systems.

Following are specifics of EFI versus BIOS boot:

• To install the operating system by way of UEFI requires that the installation be booted via UEFI and vice versa-that is, an operating system installed via BIOS can only boot via BIOS. Once the operating system is installed via EFI, it can only boot via EFI because booting via BIOS cannot access the operating system metadata (BCD boot options) on the EFI System Partition (ESP).

• Windows shipping on optical media will be able to boot either via UEFI or BIOS. El Torito multiple boot catalog support is used for this capability.

• The default El Torito boot entry will be BIOS ETFS bootstrap code with an "X86" platform tag. For this to work:

• The BIOS must support multiple boot entries.

• It must ignore entries that do not have the "x86" tag.

• It should default to booting the default entry.


• The second El Torito boot entry will be for EFI boot application and will have the "EF" platform tag. This tag points to a mountable file system containing \EFI\BOOT\BOOTX64.EFI.

EFI should ignore the PC/AT BIOS entry and recognize the EFI entry to mount the ESP partition before launching the boot application.

• For platforms supporting UEFI and BIOS, the platform should default to boot via EFI.

• Windows is planned to support both CD and DVD/UDFS boot. UDFS also uses El Torito and is built using the UDFS bridge format.

• A UEFI system requires a separate EFI system partition (ESP). BIOS systems should also implement a separate system partition for the proper functioning of Windows Vista and Windows Server 2008 features such as BitLocker Drive Encryption. This will also enable a smoother transition to EFI systems.

• For SysPrep migration between EFI and BIOS systems, Windows state should not be maintained on the system partition.
 
Thanks Kyle but in noob terms is there an advantage of enabling that option(enable UEFI boot) in the bios? Speedier boot times? Seems it will require anOS reinstall.
 
Good read. I've been confused about DDR3 and the fastest "safe" speed you can go and still get 8 GB, which looks to be 1333 from this (for all X48 chipsets actually I'd assume). So I think, given the choice of 4 GB total non-upgradeable or 8 GB cheaper at a slightly slower speed, 8 GB makes more sense (for me anyways).
 
Only 2 ram slots puts me back to athlon xp days. At work we all have 8 & 16 slot ram boards. 2 slots usable at ddr3-1600 basically makes the platform unusable IMHO.

I have 4 * 2G at home ddr2-800 @ stock, and I really wish for more.
 
I can't wait to see this review. I'm holding off building my system specifically because of this review(can't find any decent reviews of Intel motherboards). I just want something thats highly supported and super stable (overclocking would be nice, but not required). I'm tired of less-than-stellar VIA/nVidia setups.
 
Back
Top