Nice to see people hanging around. Actuality, as soon as legacy entry is fetched as a the OS you are attempting to start and firmware is identified as SCT 2.0 Clover will just quit itself and hand over control to legacy protocol. That's one of the commits I've pushed for Phoenix.
Sent from Huawei 3C using Tapatalk
@kasar, use Phoenix tool 2.14, in advanced settings select dsdt modification and the usual ones - no slic and allow users to modify other modules. Then per the standard routine press go and a table will be extracted in dsl format for you to edit. One thing to note, though. The iasl binary in Phoenix tool is ancient, so just grab a new one from acpica project.
Sent from Huawei 3C using Tapatalk
(09-04-2014, 07:39 AM)TimeWalker Wrote: [ -> ]@kasar, use Phoenix tool 2.14, in advanced settings select dsdt modification and the usual ones - no slic and allow users to modify other modules. Then per the standard routine press go and a table will be extracted in dsl format for you to edit. One thing to note, though. The iasl binary in Phoenix tool is ancient, so just grab a new one from acpica project.
huh? I am lost, what is exactly the goal of that?
you didnt told me what that does.
about acpica, are you talking about this?
https://www.acpica.org/downloads/binary-tools
also found phoenix slic tool 2.14 here:
http://www.datafilehost.com/d/acda9fb7
I supose you are talking of replace iasl.exe file from inside the phoenix slic tool folder with the one from acpica project, right?
Sorry, it was addressed to @follow_me O:-)
Sent from Huawei 3C using Tapatalk
oh, I see, its ok. haha ^^
I am not currently at the hardware modification level you guys are...
I hope to get there soon... but it will take a while..
however, as far as the uefi booting... I currently use windows 7 as my main os.. i also
have windows 8 installed on a 200gb partition at the end of my drive.. i have legacy disabled
in the bios.. both win7 and win8 bootloaders hand off to eachother.. depending on how i
have the boot order configured..
in the past.. i have used clover - however, i prefer refind.. at one point i had win7, mint 15, and mint debian working
from refind using gpt.. without legacy enabled.. however, the install media for mint debian had to use legacy in order to pick the media
up - i then manually configured its entry on the /boot partition.. refind would initially take control depending on the bios priority selection - then refine upon selection - each OS kicked in... the motherboard would automatically pick up all OS or media configuration in the /boot partition and add the entry into boot order screen.. there were times when the efi communications with the /boot partition would get corrupted.. (from all the installs and tests i did) and i had to use an editor to clean them up..
this info may not be what you are looking for.. however, it could possibly help some web surfers....
btw, i spent some time yesterday researching.. and found a few websites with some general - to - specific info and also some cool downloads..
http://www.cpyarger.com/2012/12/how-to-u...-tool.html
http://blogs.phoenix.com/phoenix_technol...os/page/2/
http://www.matrix-bios.nl/
if you research like i do - you will check out the links.. some dated but interesting info..
Good to be back guys...
Quote:Don't even try - it will kill mb in 95% cases
Thanks... hmm are there any more reliable methods to remove a soldered CPU?
(09-02-2014, 11:07 AM)jkbuha Wrote: [ -> ]1) ME modding - this is by far the most important IMO as not only will we get Ivy-bridge support but also OC and UV.
To achive this we need a stable way to reassemble firmware with custom modules. Because ME upgrade requires PEI modules update
Yes I'm building the EFI environment as we speak (thank you Virtualbox). Vanilla Tiano builds nicely, now time to integrate 016s.zip....
(09-02-2014, 11:07 AM)jkbuha Wrote: [ -> ]2) Multiplier - I think this is the easiest for me to work on as I know (in theory) what to look for; it is a case of patching & inserting efi modules and possibly tampering (again) with the EFI_FORM instructions. Happy days...
It is easy (in case if you want to do it "factory-like") - you need to unlock ICC profiles and overclocking in ME, load ICCOverclock.efi and comuncate with the driver , or just write your own, which will send requests to ME and change multyplier, clocks etc ... You can refer leaked bios sourcess (016s/Board/EM/MeWrapper/Icc/IccPlatform). And firget about hussling with byte-patching, it is no so hard to setup EFI build env and write some real code
ditto - am attempting to build the 016s code now. My descriptor is unlocked thru pin mod, but now i have the SOIC flash as well so it shouldnt be a problem to re-flash.
1) What do you mean by unlocking ICC Profiles (via fitc?) - is there an additional procedure to be applied to ME?
2) Do you have a pre-compiled ICCOverclock.efi file I can test?
(09-02-2014, 11:07 AM)jkbuha Wrote: [ -> ]Couple of questions whilst we're all on the line:
- I'm about to hot-swap the DVD with an SSD to make some experiments on UEFI booting. Has anyone managed to crisis boot from a USB (or appropriately formatted HDD/SSD)?
I'am now have Linux installed to CD-bay SSD with UEFI boot , it works fine
all you nees is to add custom boot record
I'm was able to boot from crysis usb flash. Now, with EFI shell supported in any mode, it is easy to recover using bios image with plash
Did you manage to boot via second HDD/SDD in CD-bay (as opposed to only first - I recall our SCT2.0 only allows primary HDD boot?) or does the custom boot record allow this?
Quote:@jkbuha - what exactly do we need from 2.3.1 to support new ME firmware ? (what features ?)
A long time ago I had mapped out what I thought were the necessary 2.3.1 dependencies to add to our 2.0 firmware. I had stopped short of testing it (good thing as this was pre-swappable Winbonds, crazy times) due to other priorities, but now with the EFI build system together with the hot swapping of chips we should be able to verify and experiment with these changes to see if they are indeed what I think is necessary. Will keep u posted...
Quote:BTW , about hw "flash socket mod" - I figured out a little different approach to this problem - I've made a so8 -> FFC/FPC 8 (0.5 mm pitch) adapter , which can be soldered to mb instead of flash chip and using flat cable (ffc) connected to FFC/FPC 8 -> so8 adapter
Advantages of this approach - minimum used space, clean, no wire mess, easy to change flash chips (soldered to adapters). Disadaventages - each chip is soldered to adapter, so , to connect in to HW programmer FFC/FPC -> dip adapter is required. Now I'm on a manafacturing stage (sent files to china maker), and will have all adapters in ~three weeks. I will make some photos of my mod then. If anyone want to do same way - fill free to PM me , and I'll send the files requred for adapters manufacturing
I'm always interested in other ways especially since I have two partially bricked m/bs without the SOIC modifications, so yes please
Quote:Nice to see people hanging around. Actuality, as soon as legacy entry is fetched as a the OS you are attempting to start and firmware is identified as SCT 2.0 Clover will just quit itself and hand over control to legacy protocol. That's one of the commits I've pushed for Phoenix.
Awesome work @Timewalker. Your efforts and those of the Clover team makes our crappy UEFI SCT2.0 boards usable today!
Quick update - UEFI Build Environment setup successfully.
And I've also managed to build all modules from 016s, including ICCOverclocking. Relatively easy to do for anyone with a basic knowledge of Visual Studio. Both VS2008 and VS2010 work nicely with the TianoCore base.
Driver loads successfully into EFI shell as well - I've attached the compiled efi (and ffs) driver if anyone wants to try it out and have a go.
Now next steps are to communicate with the driver. Obviously booting (into Legacy mode) into Win64 has no effect - I suspect it is because all the loaded efi modules are purged once UEFI system hands back into Legacy. I'm planning to try the following:
1) Find/Write a efi program that talks to ICCOverclocking.efi
2) Boot Windows in UEFI mode to see if XTU recognises the new driver
3) See if something similar exists in OSX, since we're in UEFI mode anyway
Be back shortly...
wait, wait, I heard about overclocking?
those are great news!
I downloaded your attacched files, I can find a ffs file and a efi file.
I supose the ffs file is used when trying to reintegrate it as module in a bios while using phoenix slic mod tool. (sadly, everytime I tried in past with the previous ffs OC modules didnt worked, doesnt matter what version of phoenix slic mod tool I used.)
about efi file, it need to be loaded using the shell efi.
I remember I managed to load modules in the shell, however, not sure how to continue with the OS loading when in shell and loaded custom modules.
we must now manage to integrate those modules inside the firmware and get they working.
oh, and really nice work jkbuha, if you acomplish this, this will be great news for everyone
Well seeing as other laptops have this module already integrated it shouldn't be so much of an effort to get this working
Load the ICCOverClocking.efi module under UEFI shell (we don't know how to properly integrate it for now). It should display "Module Loaded successfully at xxxxx".
Then next steps are to communicate with this efi driver under (i) UEFI Shell (ii) Windows (iii) OSX
For (i) I've looked at the .h file and in theory as @follow_me said it shouldn't be hard to write a script to talk to ICCOverClocking.efi
For (ii) the software already exists (it's XTU and/or CCTWin.exe) but as I've had to re-boot in legacy mode I suspect the efi has been purged from memory
For (iii) Would be nice as it is my primary OS
One other thing.
Reading through @follow_me instructions to enable the internal shell is very useful. I've mounted pflash.efi and BIOS.CAP on primary partition and bootable USB so now we can boot to shell directly from BIOS (even if it has not been unlocked). In theory we can use this method to recover from most bricks (ME notwithstanding).
Good work!