Jump to content

Clover Problems and Solutions


ErmaC
3,206 posts in this topic

Recommended Posts

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

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

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

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

Cool!  :thumbsup_anim: 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
  • Like 1
Link to comment
Share on other sites

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 :lol:  (at least also nasm)

  • Like 1
Link to comment
Share on other sites

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!

  • Like 1
Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

@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

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 works
xclang - CloverX64.efi works, boot6,7 - no
xcode5 - nothing works.


 


Let's look at this function

ASM_PFX(InitDescriptor):
lea rax, [REL GDT_BASE] ; RAX=PHYSICAL address of gdt
mov [REL gdtr + 2], rax ; Put address of gdt into the gdtr+2
lea rax, [REL gdtr]
lgdt [rax]
mov rax, 18h
mov gs, rax
mov fs, rax
lea rax, [REL IDT_BASE] ; RAX=PHYSICAL address of idt
mov qword [REL idtr + 2], rax ; Put address of idt into the idtr
lea 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 # 0x2d40
1a2b: 48 89 05 00 13 00 00 mov %rax,0x1300(%rip) # 0x2d32
1a32: 48 8d 05 f7 12 00 00 lea 0x12f7(%rip),%rax # 0x2d30
1a39: 0f 01 10 lgdt (%rax)
1a3c: b8 18 00 00 00 mov $0x18,%eax
1a41: 8e e8 mov %eax,%gs
1a43: 8e e0 mov %eax,%fs
1a45: 48 8d 05 4c 13 00 00 lea 0x134c(%rip),%rax # 0x2d98
1a4c: 48 89 05 37 13 00 00 mov %rax,0x1337(%rip) # 0x2d8a
1a53: 48 8d 05 2e 13 00 00 lea 0x132e(%rip),%rax # 0x2d88
1a5a: 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 # 0x2d33
1a2b: 48 89 05 00 13 00 00 mov %rax,0x1300(%rip) # 0x2d32
1a32: 48 8d 05 f7 12 00 00 lea 0x12f7(%rip),%rax # 0x2d30
1a39: 0f 01 10 lgdt (%rax)
1a3c: b8 18 00 00 00 mov $0x18,%eax
1a41: 8e e8 mov %eax,%gs
1a43: 8e e0 mov %eax,%fs
1a45: 48 8d 05 3f 13 00 00 lea 0x133f(%rip),%rax # 0x2d8b
1a4c: 48 89 05 37 13 00 00 mov %rax,0x1337(%rip) # 0x2d8a
1a53: 48 8d 05 2e 13 00 00 lea 0x132e(%rip),%rax # 0x2d88
1a5a: 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

×
×
  • Create New...