So, this question ref consists of:
- 1st byte: opcode (40)
- 2nd byte: size? scope? (04) or (84)
- 3rd, 4th byte: question ID (xx xx)
Where the question ID can be found in the 7th and 8th byte belonging to the setting in the IFR thingy. For instance, the suppress statement for Legacy Video Mode:
Quote:0x315AC Suppress If: {0A 82}
0x315AE Question Ref: 0x0 {40 84 32 00}
0x315B2 64 Bit Unsigned Int: 0x0 {45 0A 00 00 00 00 00 00 00 00}
0x315BC Equal {2F 02}
0x315BE End {29 02}
belongs to:
Quote:0x3154A Setting: Legacy Boot, Variable: 0x2 {05 A6 8B 00 8C 00 32 00 02 00 02 00 00 10 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00}
And the RAID options suppress statement:
Quote:0x35188 Suppress If: {0A 82}
0x3518A Question Ref: 0x0 {40 84 25 27}
0x3518E 64 Bit Unsigned Int: 0x2 {45 0A 02 00 00 00 00 00 00 00}
0x35198 Equal {2F 02}
0x3519A End {29 02}
to
Quote:0x30703 Setting: SATA Operation, Variable: 0x64 {05 A6 0E 00 0F 00 25 27 01 00 64 00 04 10 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00}
Only now as I see this, I can see it is confirmed by the Phoenix wiki. Yay. The SATA Operation one-of setting (0x05) statement consists of:
- 1st byte: opcode (05)
- 2nd byte: size (A6)
- 3rd, 4th byte: prompt string ID (0E 00)
- 5th, 6th byte: help string ID (0F 00)
- 7th, 8th byte: question ID (25 27)
...
There may be many people out there who knew this already, well, I didn't.
Alright, @Timewalker wasn't right in assuming the RAID settings would do nothing. They do. Just not exactly the right thing. How could I even have hoped for that with this crappy Ship...
I changed:
Quote:0x30703 Setting: SATA Operation, Variable: 0x64 {05 A6 0E 00 0F 00 25 27 01 00 64 00 04 10 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00}
0x30729 Default: 8 Bit, Value: 0x1 {5B 0D 00 00 00 01 00 00 00 00 00 00 00}
0x30736 Default: 8 Bit, Value: 0x1 {5B 0D 01 00 00 01 00 00 00 00 00 00 00}
0x30743 Option: ATA, Value: 0x0 {09 0E 10 00 00 00 00 00 00 00 00 00 00 00}
0x30751 Option: AHCI, Value: 0x1 {09 0E 11 00 00 00 01 00 00 00 00 00 00 00}
0x3075F End of Options {29 02}
to
Quote:0x30703 Setting: SATA Operation, Variable: 0x64 {05 A6 0E 00 0F 00 25 27 01 00 64 00 04 10 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00}
0x30729 Default: 8 Bit, Value: 0x1 {5B 0D 00 00 00 01 00 00 00 00 00 00 00}
0x30736 Default: 8 Bit, Value: 0x1 {5B 0D 01 00 00 01 00 00 00 00 00 00 00}
0x30743 Option: RAI, Value: 0x2 {09 0E 10 00 00 00 02 00 00 00 00 00 00 00}
0x30751 Option: AHCI, Value: 0x1 {09 0E 11 00 00 00 01 00 00 00 00 00 00 00}
0x3075F End of Options {29 02}
[
attachment=6249]
Which resulted in:
[
attachment=6250]
[
attachment=6248]
Of course the fun always runs out, the remainder of the firmware seems to have its own thoughts on these changes. Setting SATA operation to 'RAID' makes all SATA devices disappear to the setup utility, boot manager etc. However, if I let "RAID Alternative Device ID" be false, the UEFI Clover boot entry would start Clover, but I couldn't start OS X as the root device couln't be found. Not sure what would happen when I actually create an RAID array, but I hate moving 600 GB of data and all configuration stuff for a probable disappointment. Weird things happening in our Most Secure Core...
Ha, so you got it into thinking ATA really is raid, so it invokes the proper settings when selected. The disks would vanish until you created an actual raid array, at least this is how I remember Windows setup acted when I did mirrored raid array on H77 chipset couple of month back..
Sent from my GT-I9070 using Tapatalk
Things may not be as bad as they appeared to be. With RAID enabled but without an actual array, the HDDs report as SCSI drives. They operate correctly but the text strings on the setup main page and more importantly the HDD boot entries don't work. My entry for a UEFI application on one of the hard drivers works though, and the HDDs are visible in the UEFI shell. In WinPE, they also appear normally.
I don't care about the text strings, but the boot entries are a different story. You need them for legacy boot (right?). As they are now, their path is described by a VenMsg thingy, with a GUID that is the same for all entries and some hex data that does vary.
Quote:Option: 04. Variable: Boot0004
Desc - Hard Drive
DevPath - VenMsg(BC7838D2-0F82-4D60-8316-C068EE79D25B,F5B01CC8CE8E9841B3A8FB94B6DFEFEE00000000)
Optional- N
I am totally clueless as to where the hex data comes from. The UEFI specification nor the Phoenix wiki are very helpful. However, I probably could create a boot entry pointing to the right SCSI PUN/LUN's.
EDIT: Alright, I used bcfg boot addh to add my primary hard drive's SCSI device adress as a boot option. That worked. Sort of. It booted and showed up in the boot menu, but the boot manager in setup refused to load with so many (12) boot entries set. Reducing the amount of entries by removing Clover solved that. Then adding Clover again screwed everything up, it put itself as option 00, moving diagnostics, setup, boot menu.
I fixed it, but it seems to me that for instance bcfg boot rm 3 removes both option 03 and variable Boot0003 which are not necessarily the same, so I ended up with the optical and eSATA boot entries gone too. (Probably just my fault). Cleared variable store, solved. But this is really messy.
Btw, the RAID options under Software Feature Mask Configuration only control which RAID configurations are available in the OPROM. Leaving all those options (RAIDx and IRRT) disabled enables all (possible) RAID configurations. What I'd really like to know now is if it is possible to UEFI boot an OS from a HDD that is in a RAID configuration configured by a legacy OPROM. I think it should be, it is one of the specific purposes of the CSM.
I volunteer to test it
if you provide me with modified firmwared, I will test it against my L702X dual ssd setup
(03-22-2014, 11:15 AM)Brabbelbla Wrote: [ -> ]What I'd really like to know now is if it is possible to UEFI boot an OS from a HDD that is in a RAID configuration configured by a legacy OPROM. I think it should be, it is one of the specific purposes of the CSM.
AFAIK when the system is loaded PEI block loads stored data from bios settings and configures intel's hardware interface for software raid (is it is correct to call that) , then it just adds it as block device
@follow_me
Dual SSD... *drool*
You testing would be nice for sure. But you will lose all data on those disks and this OROM version does not support TRIM. Any experience with a custom BIOS? UEFI shell, bcfg? Guess so, just to be sure. Do you have a BIOS recovery disk? When messing with NVRAM for the boot variables that could come in handy. If not, I recently created one for myself.
(03-23-2014, 11:19 PM)follow_me Wrote: [ -> ]AFAIK when the system is loaded PEI block loads stored data from bios settings and configures intel's hardware interface for software raid (is it is correct to call that) , then it just adds it as block device
AFAIK it does. But it was not what I meant, I thought about how a UEFI-aware OS would handle a legacy OROM RAID configuration. But let's just see.
> OROM version does not support TRIM.
Thats sad, but I'l try
Any experience with a custom BIOS? UEFI shell, bcfg? Guess so, just to be sure. Do you have a BIOS recovery disk? When messing with NVRAM for the boot variables that could come in handy. If not, I recently created one for myself.
Heavy experience with custom rom. UEFI Shell. AFAIK I was first who got pflash tool for UEFI. I have a hardware backup of the rom chip (desoldered original one), Couple times bricked my system , and know how to restore it
I know what I'm doing
There you go then. It seems it is possible to edit newer OROMs into thinking they can perform TRIM in RAID on 6-series chipsets, but I have not ventured there.