(UEFI) Dell XPS 15z L511z modded BIOS - and HOWTO

[thorbsd]

I'm just wondering if you guys could help me understand a little bit more about UEFI. I've never set up any OS with UEFI and I'm not totally clear on how everything fits together.

My impression for the old BIOS type system is this:
Power on -> BIOS loads -> boot loader on first sector of HD (installed by the OS) -> OS loads

My impression for UEFI type system is this:
Power on -> UEFI loads -> UEFI bootloader (which is already installed from the manufacturer (edk2?)) -> OS install creates an entry in the UEFI bootloader -> OS loads

Then if someone installs something like "Clover EFI" it's just a more feature filled replacement UEFI bootloader than the one that's already installed by the manufacturer? Does the UEFI bootloader reside within memory space present on the UEFI chip itself, or is it located on the hard drive? I was under the impression it was located on the chip itself.

Also, in the case of the XPS 15z, when using the "legacy mode", the computer is still operating off UEFI except it is simply emulating the BIOS environment and you use the MBR based OS installations as usual.

[TimeWalker]

My impression for the old BIOS type system is this:
Power on -> BIOS loads -> boot loader on first sector of HD (installed by the OS) -> OS loads

BIOS > MBR -> PBR > BOOTLOADER > OS

My impression for UEFI type system is this:
Power on -> UEFI loads -> UEFI bootloader (which is already installed from the manufacturer (edk2?)) -> OS install creates an entry in the UEFI bootloader -> OS loads

UEFI > BOOTLOADER.EFI > OS

Then if someone installs something like "Clover EFI" it's just a more feature filled replacement UEFI bootloader than the one that's already installed by the manufacturer? Does the UEFI bootloader reside within memory space present on the UEFI chip itself, or is it located on the hard drive? I was under the impression it was located on the chip itself.

If someone *installs* CloverEFI (an emulated EFI firmware based on DUET/EDKII) it will be a case of legacy boot with emulated EFI environment. Basically obtaining hardware information from BIOS, then passing it over to a fake firmware, which resides on a HDD media. The boot process in such case is:
BIOS > MBR > PBR > boot1h > boot > Clover.efi > BOOTLOADER.EFI > OS

Also, in the case of the XPS 15z, when using the "legacy mode", the computer is still operating off UEFI except it is simply emulating the BIOS environment and you use the MBR based OS installations as usual.

That's correct. In fact, Dell went down this road and locked down the machine in emulated BIOS scenario from the factory as the firmware clearly has memory allocation issues. In UEFI mode runtime services fail to start, there are CPU deadlocks and firmware frequently tries to write outside the available memory regions (Fn+F2, QuickSet..).

[thorbsd]

Thanks for the explanation, it cleared a few things up.

So UEFI booting doesn't work properly on the 15z (with the modded A12 BIOS found here)? Or more specifically, it will boot, but there will be issues once you boot into the OS?

[TimeWalker]

It wasn't meant to be in the first place so there was something that made Dell lock it down and we have now found this *Something, Something, Something, Dark Side* - it just doesn't really scale very well. When a board with proper NVRAM support would scale GNVS region memory allocation and change it based on what you set in the BIOS, on this generation of Dell GNVS remains fixed and never changes. So, when it comes to writing something into the memory space that would normally be accessible in UEFI boot it just freezes the system down to a point where you have to physically power it down from the PWRBTN because there is not address that corresponds to the destination.

UEFI install of Windows is somewhat usable if you can deal with some quirks -> http://forum.notebookreview.com/dell-xps...ost9307506 (same applies for 15z)
UEFI Clover for booting OSX is totally usable if you keep your laptop as a desktop machine, basically. Which only means that you put it to sleep more frequently, than you actually shut it down. Because with UEFI Clover shutdown is broken on SC Tiano firmware.

[jkbuha]

And all the more I keep thinking that there must be a way to upgrade the UEFI firmware to 2.31 and beyond...

There must be someone out there who has attempted this, even if unsuccessful.

[jkbuha]

Morning y'all - New week, new event.

Intel has just posted the new CPU microcode updates (all our i5+i7 families have been updated to 0x29) and I've patched the 15z bios microcode to support this. Two interesting things happened:

1) Windows 8 bluescreened on boot. No safe mode, auto repair could make it work. Windows 7 (and XP) worked fine. In fact I had to reboot into an emergency pen drive with W7 just to reflash the previous bios with 0x25 microcode. Note that both Linux and OSX worked fine with the new microcode.

2) Under Linux I noticed something interesting. As both Windows & Linux automatically update the microcode on boot (depending on the latest apt-get, service pack etc) all were updated (downgraded) to 0x28. However with the new microcode CPU0 and CPU1 (the two threads of the first core) were running 0x29 whilst CPU2 and CPU3 were disabled (microcode 0x00). Might be the reason why W8 wasn't too happy. Then again all geekbench scores under Linux+OSX had the same scores as with 0x28 so it might just be an anomaly on reporting.

3) I've also just realised one other thing; for those of us who run OSX we will not get the latest microcode updates unless we manually patch them into the BIOS.

Thoughts?

Nice weekend to all

[broucaries]

Morning y'all - New week, new event.

Intel has just posted the new CPU microcode updates (all our i5+i7 families have been updated to 0x29) and I've patched the 15z bios microcode to support this. Two interesting things happened:

1) Windows 8 bluescreened on boot. No safe mode, auto repair could make it work. Windows 7 (and XP) worked fine. In fact I had to reboot into an emergency pen drive with W7 just to reflash the previous bios with 0x25 microcode. Note that both Linux and OSX worked fine with the new microcode.

2) Under Linux I noticed something interesting. As both Windows & Linux automatically update the microcode on boot (depending on the latest apt-get, service pack etc) all were updated (downgraded) to 0x28. However with the new microcode CPU0 and CPU1 (the two threads of the first core) were running 0x29 whilst CPU2 and CPU3 were disabled (microcode 0x00). Might be the reason why W8 wasn't too happy. Then again all geekbench scores under Linux+OSX had the same scores as with 0x28 so it might just be an anomaly on reporting.

3) I've also just realised one other thing; for those of us who run OSX we will not get the latest microcode updates unless we manually patch them into the BIOS.

Thoughts?

Nice weekend to all

New microcode is known to restrict some chipset operation in order to avoid overcloaking/hard modification see http://www.bit-tech.net/news/hardware/20...ng-block/1

[kasar]

New microcode is known to restrict some chipset operation in order to avoid overcloaking/hard modification see http://www.bit-tech.net/news/hardware/20...ng-block/1

thanks for the info.

then I will stick happyly to my 0x28 version, working great and no [censored] restrictions

[broucaries]

BTW I have achieved to get aspm (pci energy saving), by setting pcie to native under linux... (and less firmware bug) and it is a battery life savor

Still I have some firmaware bug detected by linux:
- usb controler problem:
* usb 4-1:1.0: over-current condition on port 1
* hub 4-1:1.0: over-current condition on port 2
seems upgrading the microcode of the usb controler help
- [drm] Wrong MCH_SSKPD value: 0x16040307
[drm] This can cause pipe underruns and display issues.
[drm] Please upgrade your BIOS to fix this.
- ACPI: Interpreter enabled
ACPI Exception: AE_NOT_FOUND, While evaluating Sleep State [\_S1_] (20130328/hwxface-568)
ACPI Exception: AE_NOT_FOUND, While evaluating Sleep State [\_S2_] (20130328/hwxface-568)
*Clearly a acpi bug *

May we test bios with https://code.google.com/p/linuxfirmwarek...runk/BUILD

Moreover why not starting to implement coreboot ?

Bastien

---

New microcode is known to restrict some chipset operation in order to avoid overcloaking/hard modification see http://www.bit-tech.net/news/hardware/20...ng-block/1

thanks for the info.

then I will stick happyly to my 0x28 version, working great and no [censored] restrictions

The good question is why windows modify this forbidden register after lock...

BTW I believe that firmware upgrade render these register read only only after upgrade so you could overclock but before upgrading the firmware (that correct a critical security bug unfortunatly not documented that allow to bypass paging)

[jkbuha]

Nice work @broucaries - rep added. I had missed this, so thanks for the heads up. @kasar - the microcode patch is applied at OS level as well (Win/Linux) so eventually your proc will get updated to 0x29 as well - already done thru Linux and soon to follow via service update on windows.