Zenith432 Posted April 16, 2016 Share Posted April 16, 2016 Your boot3+BOOTIA32.efi work in the sense that they show the menu, the 32-bit shell and bdmesg work. There's no 32-bit OS for them to boot. Thanks , I cannot try 32bit files too Link to comment Share on other sites More sharing options...
Micky1979 Posted April 16, 2016 Share Posted April 16, 2016 Is good no? Here the cctools+patches used:cctools-877.5.zip Link to comment Share on other sites More sharing options...
JorgeMax Posted April 16, 2016 Share Posted April 16, 2016 Personally, I am using the 3438 review of Clover EFI. In the boot screen of the Mavericks, is black without bootlogo. The system starts and goes to the table, but without the two logos of Apple. Link to comment Share on other sites More sharing options...
droples Posted April 16, 2016 Share Posted April 16, 2016 Personally, I am using the 3438 review of Clover EFI. In the boot screen of the Mavericks, is black without bootlogo. The system starts and goes to the table, but without the two logos of Apple. Update Clover up to 3443 or higher. https://sourceforge.net/p/cloverefiboot/code/3443/ 1 Link to comment Share on other sites More sharing options...
Zenith432 Posted April 16, 2016 Share Posted April 16, 2016 It means a crash in FileDevicePathToStr (gEfiBootDeviceData)[/size] size=528241204 cause me doubts The 528241204 is because the first call returns NULL. I think it's normal. FileDevicePathToStr is in GenericBdsLib, for which GCC uses -fno-lto. So, while having no way to reproduce this bug for testing, I set -fno-lto on XCODE for the two modules in which GCC has them (GenericBdsLib, OsxBdsDxe). Now -xcode5 boot6 is too big for low-ebda, and needs --std-ebda. Link to comment Share on other sites More sharing options...
Zenith432 Posted April 16, 2016 Share Posted April 16, 2016 Something wrong here [Sources.X64] X64/AsmFuncsX64.asm #X64/AsmFuncsX64.S | GCC X64/AsmFuncsX64.S | XCODE X64/AsmFuncsX64.nasm | GCC It assumes that XCODE5 and XCLANG will use X64/AsmFuncsX64.S and compile them by clang.Anyway I see [NASM] AsmFuncsX64[/size] Why? From TFM BUILDRULEFAMILY This flag is used by some tool chain tags to set a special FAMILY value when processing the build_rule.txt file. Normally, the FAMILY attribute is used to identify the type of makefile the tools need to generate. Tools such as XCODE will use GCC as the FAMILY, but uses different (from GCC) processing rules. If present and if a build rule (in build_rules.txt) contains an attribute with the value specified in this entry, that rule will be processed and the rule with the FAMILY attribute will be ignored. BUILDRULEORDER This attribute is used by tools to process files listed in INF [sources] sections in priority order. If a filename is listed with multiple extensions, the tools will use only the file that matches the first extension in the space separated list. Example: [sources] Foo.s Foo.asm Foo.nasm The tools_def.txt file has the entry. *_*_*_*_BUILDRULEORDER = nasm asm Asm ASM S s The Foo.nasm file will be processed, and the Foo.s and Foo.asm files will be ignored during the build. If a file is listed in the [sources] section and the file extension is not listed a section that is specified for a build FAMILY (or BUILDRULEFAMILY if specified as an attribute in the build_rule.txt file) for the selected tool chain (GCC for example) in the build_rule.txt file, then the file is ignored. For example, if the INF has the following section listed: UefiCpuPkg/Library/BaseUefiCpuLib/BaseUefiCpuLib.inf [sources.IA32] Ia32/InitializeFpu.asm Ia32/InitializeFpu.S [sources.X64] X64/InitializeFpu.asm X64/InitializeFpu.S If the tool chain is a GCC tool chain, then only the .S files would be processed and the .asm files will be ignored. Link to comment Share on other sites More sharing options...
LockDown Posted April 17, 2016 Share Posted April 17, 2016 I will be testing your boot3 in a while, as i have netbook N280 running 10.6.8. Is that ok for testing? Link to comment Share on other sites More sharing options...
Micky1979 Posted April 17, 2016 Share Posted April 17, 2016 sure! As Zenith432 said boot3 builted w -xcode5 can reach the menu also on my system and show me all my drives. Last time I tried (long time ago btw) only a reboot was happened. Should be nice to see if work by chances sosbstituting all 32bit files. my setup is: xcode 7.3 clt 7D175 nasm built-in mtoc from cctool877.5+new lto from llvm (posted) I guess you need to start Snow in 32bit too Link to comment Share on other sites More sharing options...
LockDown Posted April 17, 2016 Share Posted April 17, 2016 Success booting boot3 on my atom x32 n280. Running 32bit of SL of course Link to comment Share on other sites More sharing options...
Micky1979 Posted April 17, 2016 Share Posted April 17, 2016 Replaced all binaries? Link to comment Share on other sites More sharing options...
LockDown Posted April 17, 2016 Share Posted April 17, 2016 Its a fresh install, thats why took me so long to reply. all clover files are from your CloverV2 zip 1 Link to comment Share on other sites More sharing options...
Micky1979 Posted April 17, 2016 Share Posted April 17, 2016 Cool! latest changes by Zenith432 are very good! cd "${src}"/edk2/Clover svn up ./ebuild.sh -x64 -xcode5 ./ebuild.sh -mc -xcode5 ./ebuild.sh --ia32 -xcode5 cd "${src}"/edk2/Clover/CloverPackage make clean make pkg installer make image iso 1 Link to comment Share on other sites More sharing options...
LockDown Posted April 17, 2016 Share Posted April 17, 2016 (edited) is that with gcc5.3? Can you share the compile script? Edited April 17, 2016 by ellaosx Link to comment Share on other sites More sharing options...
Micky1979 Posted April 17, 2016 Share Posted April 17, 2016 no, xcode7.3 alone... EDIT ok xcode7.3 + command line tools for xcode7.3 + mtoc.NEW (what make the difference?), offcourse gettex for translating the po files for the packages. the line to compile gcc are also commented: # ./build_gcc5.sh # ./buildgcc-4.9.sh ..not used, just I'm guessing on how it's safe ... but is cool to install only gettex once to build Clover (at least also nasm) 1 Link to comment Share on other sites More sharing options...
LockDown Posted April 17, 2016 Share Posted April 17, 2016 I will be here to test boot3 for you guys Link to comment Share on other sites More sharing options...
Micky1979 Posted April 17, 2016 Share Posted April 17, 2016 My intrest is to build with xcode, but should be safe, let see developers thought.. Can you share the compile script? Is done for Pandora and works with directories structure that you can't have, BTW I'm just replacing the boot1-install source with one coming with chameleon because self-force-umount the target partition for my purpose + I add the boot0xg to be used as replacement for boot0af on some bioses. Basically no modification to the source from sourceforge! 1 Link to comment Share on other sites More sharing options...
LockDown Posted April 17, 2016 Share Posted April 17, 2016 what is mtoc.new anyway? Iv been compiling clover w/o an issue, then suddenly im hearing this several posts above I dont even know if i have that installed. All i know is, i can compile a working clover. Link to comment Share on other sites More sharing options...
Micky1979 Posted April 17, 2016 Share Posted April 17, 2016 Clover can be builted in linux, Windows and OSX using different compiler... and here, If you taken your script somewere (or you are following what's on in the Clover WIKI) probably are you using GCC 4.9 that offcourse is the only reccomended until now because is fully working... certain that he works!! Instead mtoc is part of the compiler tools provided by apple and here is modded to extend lto functionalities. It used to produces working .efi files, in short, using the Apple tools. Clover search it in /usr/local/bin/ only when you use xcode toolchain for example, but this depend on what arguments you provide to the ebuild.sh script. No need with GCC 4.9 or 5.3. 1 Link to comment Share on other sites More sharing options...
LockDown Posted April 17, 2016 Share Posted April 17, 2016 ^^ Wonderfull. Fully understand. Thank You! 1 Link to comment Share on other sites More sharing options...
LockDown Posted April 18, 2016 Share Posted April 18, 2016 @Mickey1979 the "usual" script (gcc4.9) no longer boot boot3. blackscreen after GUI but its ok Link to comment Share on other sites More sharing options...
cecekpawon Posted April 18, 2016 Share Posted April 18, 2016 Skip Intel Ports, NVCAP / RefCLK, LoadVideoBios in GUI-menu, please test Link to comment Share on other sites More sharing options...
Slice Posted April 18, 2016 Share Posted April 18, 2016 @Zenith432 CloverX64.efi rev3448 stops at the same place. This is clean compilation. Oops! I reverted -fno-lto, will text again. @cecekpawn. I committed your patch to 3349 without careful analysis. I think you are right. EDITED. Anyway all problems at the same place: gcc49 - all works xclang - CloverX64.efi works, boot6,7 - no xcode5 - nothing works. Link to comment Share on other sites More sharing options...
Micky1979 Posted April 18, 2016 Share Posted April 18, 2016 xcode5 - nothing works. booted using an '-xcode5' build here... legacy or UEFI with no apparently problems Link to comment Share on other sites More sharing options...
Zenith432 Posted April 18, 2016 Share Posted April 18, 2016 There is something wrong with your nasm. I took apart the boot5 that you uploaded here. I found Cpu.dxe inside it by searching for the code of CpuDxe/X64/CpuInterrupt.nasm.Then compared the code with the one from my build of boot6 (which works.)See below for result. EDITED.Anyway all problems at the same place:gcc49 - all worksxclang - CloverX64.efi works, boot6,7 - noxcode5 - nothing works. Let's look at this function ASM_PFX(InitDescriptor):lea rax, [REL GDT_BASE] ; RAX=PHYSICAL address of gdtmov [REL gdtr + 2], rax ; Put address of gdt into the gdtr+2lea rax, [REL gdtr]lgdt [rax]mov rax, 18hmov gs, raxmov fs, raxlea rax, [REL IDT_BASE] ; RAX=PHYSICAL address of idtmov qword [REL idtr + 2], rax ; Put address of idt into the idtrlea rax, [REL idtr]lidt [rax]ret Here's what a disassembly of a good build looks like 1a24: 48 8d 05 15 13 00 00 lea 0x1315(%rip),%rax # 0x2d401a2b: 48 89 05 00 13 00 00 mov %rax,0x1300(%rip) # 0x2d321a32: 48 8d 05 f7 12 00 00 lea 0x12f7(%rip),%rax # 0x2d301a39: 0f 01 10 lgdt (%rax)1a3c: b8 18 00 00 00 mov $0x18,%eax1a41: 8e e8 mov %eax,%gs1a43: 8e e0 mov %eax,%fs1a45: 48 8d 05 4c 13 00 00 lea 0x134c(%rip),%rax # 0x2d981a4c: 48 89 05 37 13 00 00 mov %rax,0x1337(%rip) # 0x2d8a1a53: 48 8d 05 2e 13 00 00 lea 0x132e(%rip),%rax # 0x2d881a5a: 0f 01 18 lidt (%rax)1a5d: c3 retq And this is what a disassembly of this function from your boot5 looks like 1a24: 48 8d 05 08 13 00 00 lea 0x1308(%rip),%rax # 0x2d331a2b: 48 89 05 00 13 00 00 mov %rax,0x1300(%rip) # 0x2d321a32: 48 8d 05 f7 12 00 00 lea 0x12f7(%rip),%rax # 0x2d301a39: 0f 01 10 lgdt (%rax)1a3c: b8 18 00 00 00 mov $0x18,%eax1a41: 8e e8 mov %eax,%gs1a43: 8e e0 mov %eax,%fs1a45: 48 8d 05 3f 13 00 00 lea 0x133f(%rip),%rax # 0x2d8b1a4c: 48 89 05 37 13 00 00 mov %rax,0x1337(%rip) # 0x2d8a1a53: 48 8d 05 2e 13 00 00 lea 0x132e(%rip),%rax # 0x2d881a5a: 0f 01 18 lidt (%rax)1a5d: c3 retq Look at the offsets of the references to some of the data items... they're wrong.I'm using prebuilt binary of nasm downloaded form here. Edit: Could be this. Link to comment Share on other sites More sharing options...
Slice Posted April 18, 2016 Share Posted April 18, 2016 iMac:2 slice$ nasm -v NASM version 2.11.05 compiled on May 21 2014 iMac:2 slice$ May be this version is wrong but how gcc49 compilation works in this case? Link to comment Share on other sites More sharing options...
Recommended Posts