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

[Brabbelbla]

Maybe I should have been clearer, just had an exam, pretty spent now. -b is for 'break', allowing you to read everything in the list. If you export it, don't use it.

[kasar]

oh,didn't knew the parameter meaning, next time I'll use just dh without parameters, but well, I noticed it didnt got cut on the output.

anyway, relating what you said, I cant see your raid driver.

[follow_me]

I see. Actually none of the flash drivers are displayed by 'drivers'. Maybe some were at some stage? Doesn't the BIOS image get shadowed in memory? Maybe they were unloaded after that.

Anyway, I believe in Phoenix BIOSes normally RaidEfiRom/SataDriver gets called by PlatformPci(Dxe), there is a reference in it to (one of) the protocol(s) published by RaidEfiRom. In the AMI source code it is loaded from SBDxe, which I guess covers the same function as PlatformPciDxe. It is loaded really early, if I see it correctly only the RetrainLink 'procedure' precedes it.

So maybe the driver ran at the wrong stage when I plainly replaced SystemIsaFloppyDxe with it. If kasars test doesn't work, maybe the solution would be a custom UEFI driver replacing PlatformPci, that loads the RaidEfiRom and then PlatformPci (and maybe other drivers, replacing the VBIOS with GOP drivers could be nice) from some other location; a sacrificed (flash part?) module. Does that sound plausible?

In principle, RaidEfiRom/SataDriver is a generic driver, so the code should be OK, I guess.

@Brabbelbla
Idea is nice - but Raid driver is deppends on PlatformPci and should be loaded after, and you are right - SystemIsaFloppyDxe is not the place it should be. I see some problems here - first of all there is a system loader , which know nothing about new RAID driver, and will load existing driver/OROM according to the setup preferences - which can make a conflict between system and RAID drivers (for example - owerwritten protocol pointers ). Second one - we should insert it just in right position - after all required drivers are loaded and just before system enumerated boot block devices , or you will get situationlike with boot flash drive when it is inserted in wrong time - you see it, from shell , but it is not available from boot menu 

I think it will be nice if we could insert original PlatformPci  as separate module  with new image guid (not replace existing one), then replace original PlatformPci image with custom loader , which will load then image with the new PlatformPci guid , and then  Unload existing drivers if needed and load   additionl ones

Can you try to insert a new module ? 

Btw - we can upgrade our system up to 2.4 spec by loading modules with missing protocols if all this will work

[Brabbelbla]

@follow_me
The way you describe it would be best. However, in my experience adding a new driver doesn't work, and replacing existing GUIDs, for instance the flash part driver, could fulfill our purpose, although it is not ideal and there is the risk of drivers getting picked up too early. On the other hand, if nothing checks those specific GUIDs/image handles, which would be nasty code IMHO, it should be fine. An alternative might be changing the GUID, but I haven't ever really seriously tried that. Maybe those things work with the latest PhoenixTool version, but haven't tried that yet. On topic of loading the RAID driver, it seems to work like the following in the AMI code:

1. DXE dependency of the RAID driver published what is named an execution GUID;
   
2. SBDxe checks policies, settings, etc., if those are good to go, it uses InstallProtocolInterface with the RAID driver's execution GUID.
   

I am not really familiar with the concept 'protocol', and with the install function even more so, maybe you are more familiar with that. Does installing that execution protocol interface mean the driver gets processed/loaded/'run'? If it does, it would allow for a very compact code replacing the PlatformPci GUID to first install the RAID driver execution protocol interface and have it run, and then use the same procedure for passing control to the actual PlatformPci. If not, I guess StartImage could be used for the latter, while the first could be left to the DXE dispatcher or whatever, just like it is done in AMI's implementation.

Then I think you are right about the existing OROM, in my earlier experiment it ran alongside the UEFI driver. In AMI's code, there exists a protocol called CSM_OPROM_POLICY, in both their 7 series code with the SataDriver, and their older code. This protocol is registered in SBDxe, so the SbCheckOprom function gets called whenever an event is registered on it. In the 7 series code, this function then specifically checks whether it is the RAID OROM and whether it is desired for it to run, and pushes the result back to CSM_OPROM_POLICY. I think a similar protocol should exist in our BIOSes (seeing http://wiki.phoenix.com/wiki/index.php/E..._HOOK_MODE) that we could use to do the same, but then we need to know its GUID and usage.

[follow_me]

I am not really familiar with the concept 'protocol', and with the install function even more so, maybe you are more familiar with that. Does installing that execution protocol interface mean the driver gets processed/loaded/'run'? If it does, it would allow for a very compact code replacing the PlatformPci GUID to first install the RAID driver execution protocol interface and have it run, and then use the same procedure for passing control to the actual PlatformPci. If not, I guess StartImage could be used for the latter, while the first could be left to the DXE dispatcher or whatever, just like it is done in AMI's implementation.

Then I think you are right about the existing OROM, in my earlier experiment it ran alongside the UEFI driver. In AMI's code, there exists a protocol called CSM_OPROM_POLICY, in both their 7 series code with the SataDriver, and their older code. This protocol is registered in SBDxe, so the SbCheckOprom function gets called whenever an event is registered on it. In the 7 series code, this function then specifically checks whether it is the RAID OROM and whether it is desired for it to run, and pushes the result back to CSM_OPROM_POLICY. I think a similar protocol should exist in our BIOSes (seeing http://wiki.phoenix.com/wiki/index.php/E..._HOOK_MODE) that we could use to do the same, but then we need to know its GUID and usage.

@Brabbelbla
"Protocol" is a set of function pointers tied to GUID. "Installing" means placing this pointers into system tables. It is possible to hook any protocol to custom one , and it's easy, just replacing original pointer into custom one. It can be replaced by some proxy functions like "do the stuff and route arguments back to the original function". The only issue here is timing - proxy driver should run ASAP , idealy it should be the first one module loaded , hooked for example "load" protocol , and make custom dispatching, and some logging 
I think we should make an app to digg inside the boot process , find out load sequence, replace earliest driver loaded we can and then rule whole process 

[determo13]

Hi guys, just to let you know, I tryed to get info on fernandos forum... Not much, but strange enought he couldnt find option rom...
Anyway here is the answer:

I am sorry, but I cannot help you with this sort of BIOS modding.
The AMI Aptio MMTool v4.50.0.23 is able to open both files, but doesn't show the Option ROM modules.
Then I extracted the contents of both BIOS files by using the PhoenixTool, but I don't have the needed experience with that tool.

[determo13]

Hi guys you are silent these days. 
Kasar are you still up to perform crazy tests with your l502x?
If yes, could you flash your bios with that modded bios from l702x
then, in RAID mode, boot the shell, and use the 'dh -b' command to see if device is there?
They guy from other forum said:
"I am not willing to support your plan to get RAID support into a sytem, which obviously not even has an operable on-board RAID Controller."
That at least going to proof that l502x RAID controller works....

[cutecool]

hi i am new to this forum n this is my first post. i have dell xps15z with bios A12 original, i was trying to install linux on win8.1 and was having various difficulties, i came across this forum and page, and 188 pages are a lot to read but it looks friendly community, well ill try the OP stuff and revert..

IS there any step by step guide

[Brabbelbla]

@cutecool
Hi A guide for what?

@determo13
Point is that how easy porting "every module related to RAID etc." may sound, me being (actually in the process of becoming) a scientist, vagueness in general is something I hate to work with. I'd like to help you, but to do what you say would make me manually sort out the differences between the L502X and the L702X for every module. If you want to get that done, I encourage you to do it, and I will try to help you in using the results. Seeing AMI's sources, different parts needed for RAID functionality are implemented in different modules, so to do anything I believe in I like to have an overview of the differences.

[determo13]

@Brabbelbla
Sounds great! I would love to try compare things if it can solve the problem.
I have phonenix tool and going to compare 2 bioses like this:


So what exactly I need to provide you from here? names of not similar modules?