Jump to content
8755 posts in this topic

Recommended Posts

24 minutes ago, Download-Fritz said:

@MacNB This has nothing (directly) to do with OC, some garbage (cough AMI cough) FAT drivers do corrupt the FS when writing, yes.

 

That's what I was thinking. Are any external FAT.efi that can be loaded by OC to override the firmware ?

Thanks.

Hi guys,

 

What's the difference between "layout-id" and "alc-layout-id"?

 

The reason why I'm asking is because the Configuration pdf mentions "layout-id" as the key we need to use in Device Properties. Same thing for the sample.plist. But...in ioreg, the value I enter as "layout-id" gets displayed under "alc-layout-id". And I get another value displayed as "layout-id". So...I'm confused.

 

For example:

I want layout-id 15, so I enter layout-id 0F000000 (reversed bytes) in Device Properties.

However, when I check the ioreg (HDEF section), the "layout-id" is 07000000 and the "alc-layout-id" is actually the one with value 0F000000.

 

I'm a bit confused. I do have sound either way, by the way. Just wanted to know more about this, if possible. Cause it seems strange. And I'm sure there's something I'm missing here. :) 

Edited by arsradu
  • Like 1
26 minutes ago, arsradu said:

Hi guys,

 

What's the difference between "layout-id" and "alc-layout-id"?

 

The reason why I'm asking is because the Configuration pdf mentions "layout-id" as the key we need to use in Device Properties. Same thing for the sample.plist. But...in ioreg, the value I enter as "layout-id" gets displayed under "alc-layout-id". And I get another value displayed as "layout-id". So...I'm confused.

 

For example:

I want layout-id 15, so I enter layout-id 0F000000 (reversed bytes) in Device Properties.

However, when I check the ioreg (HDEF section), the "layout-id" is 07000000 and the "alc-layout-id" is actually the one with value 0F000000.

 

I'm a bit confused. I do have sound either way, by the way. Just wanted to know more about this, if possible. Cause it seems strange. And I'm sure there's something I'm missing here. :) 

 

My IOREG shows alc-layout=<07 00 00 00> and layout-id=<07 00 00 00>.

In my Device Properties = 07 00 00 00

 

Not sure why yours are different.

May AppleALC driver is alc-layout-id ?

But different ? Hmmm

 

A lot folks used to add layout id's via boot-args. 

May be check yours if you had it in the past forgot to take it out...just thinking out loud.

There currently is no way to install a custom FAT driver without flashing it into the firmware. This quite uneasy, and since the issue is resolved with APTIO V (Broadwell+) we will unlikely ever work on it.

 

The correct way to inject the layout is to use layout-id. alc-layout-id is an internal thing AppleALC uses, and it is correct that AppleALC then renames your value to alc-layout-id. The internal kitchen behind the values is that different layout-id values may have different predefined DSP properties in AppleHDA userspace libraries. To avoid a conflict AppleALC always uses a constant value of layout-id 7 for all the libraries. Your injected value on the other side becomes only relevant to AppleALC itself (as it chooses the layout based on it). This value remains present in I/O Registry under the name of alc-layout-id for debugging reasons.

  • Like 4
1 hour ago, arsradu said:

Hi guys,

 

What's the difference between "layout-id" and "alc-layout-id"?

 

The reason why I'm asking is because the Configuration pdf mentions "layout-id" as the key we need to use in Device Properties. Same thing for the sample.plist. But...in ioreg, the value I enter as "layout-id" gets displayed under "alc-layout-id". And I get another value displayed as "layout-id". So...I'm confused.

 

For example:

I want layout-id 15, so I enter layout-id 0F000000 (reversed bytes) in Device Properties.

However, when I check the ioreg (HDEF section), the "layout-id" is 07000000 and the "alc-layout-id" is actually the one with value 0F000000.

 

I'm a bit confused. I do have sound either way, by the way. Just wanted to know more about this, if possible. Cause it seems strange. And I'm sure there's something I'm missing here. :) 

 

This might help you. https://dortania.github.io/OpenCore-Desktop-Guide/post-install/audio.html#making-layout-id-more-permanent

  • Like 2
6 minutes ago, vit9696 said:

The correct way to inject the layout is to use layout-id. alc-layout-id is an internal thing AppleALC uses, and it is correct that AppleALC then renames your value to alc-layout-id.

 

The internal kitchen behind the values is that different layout-id values may have different predefined DSP properties in AppleHDA userspace libraries. To avoid a conflict AppleALC always uses a constant value of layout-id 7 for all the libraries. Your injected value on the other side becomes only relevant to AppleALC itself (as it chooses the layout based on it). This value remains present in I/O Registry under the name of alc-layout-id for debugging reasons.

 

All clear. Thank you! :) 

 

Also, funny you said "internal kitchen". We actually have an identical version of that in RO. You can translate it word by word and it would mean the exact same thing. :))

 

Once again, thank you! :) 

 

Edited by arsradu
51 minutes ago, arsradu said:

Hi guys,

 

What's the difference between "layout-id" and "alc-layout-id"?

 

The reason why I'm asking is because the Configuration pdf mentions "layout-id" as the key we need to use in Device Properties. Same thing for the sample.plist. But...in ioreg, the value I enter as "layout-id" gets displayed under "alc-layout-id". And I get another value displayed as "layout-id". So...I'm confused.

 

For example:

I want layout-id 15, so I enter layout-id 0F000000 (reversed bytes) in Device Properties.

However, when I check the ioreg (HDEF section), the "layout-id" is 07000000 and the "alc-layout-id" is actually the one with value 0F000000.

 

I'm a bit confused. I do have sound either way, by the way. Just wanted to know more about this, if possible. Cause it seems strange. And I'm sure there's something I'm missing here. :) 

 

You shall inject a layout-id in Device Properties (or boot-arg), but in IOReg you will see it as alc-layout-id.

You also will always see layout-id 7 in IOReg (Specifics AppleALC for compatibility with any layout-id).

And by the way, your question is an offtopic.

17 minutes ago, Andrey1970 said:

 

You shall inject a layout-id in Device Properties (or boot-arg), but in IOReg you will see it as alc-layout-id.

You also will always see layout-id 7 in IOReg (Specifics AppleALC for compatibility with any layout-id).

And by the way, your question is an offtopic.

 

Thank you. But...why is my question off-topic on a thread regarding OpenCore, when the question refers to adding layout-id to Device Properties to the config that OpenCore is using? Isn't OpenCore the topic? Isn't its config part of the topic? :))

 

I mean...I know this is probably more related to AppleALC than OC itself, but I wouldn't call it off-topic. I can post my future questions in the dedicated threads. But that's the thing. They're not used separately. They're used with OpenCore or Clover or whatever. And the thing I was referring to was the config plist. It's literally in the Configuration pdf for OpenCore.

Edited by arsradu
19 minutes ago, vit9696 said:

There currently is no way to install a custom FAT driver without flashing it into the firmware. This quite uneasy, and since the issue is resolved with APTIO V (Broadwell+) we will unlikely ever work on it.

 

So it's older firmware issue. Mine is Ivy Bridge. Got it. 

 

So adding the Fat.efi driver from Clover to OC/Drivers will make no difference ?

10 minutes ago, MacNB said:

 

So it's older firmware issue. Mine is Ivy Bridge. Got it. 

 

So adding the Fat.efi driver from Clover to OC/Drivers will make no difference ?

 

Yes, it will work. You could even get a working one from newer firmware and have it reconnect as well. I imagine that OC is going to do that for you automatically when drivers are loaded.

Edited by apianti
  • Like 1
3 minutes ago, arsradu said:

Thank you. But...why is my question off-topic on a thread regarding OpenCore, when the question refers to adding layout-id to Device Preferences to the config that OpenCore is using? Isn't OpenCore the topic? Isn't its config part of the topic? :))

 

I mean...I know this is probably more related to AppleALC then OC itself, but I wouldn't call it off-topic. I can post my future questions in the dedicated threads. But that's the thing. They're not used separately. They're used with OpenCore or Clover or whatever. And the thing I was referring to was the config plist.

 

Your question isn't related to OpenCore. 

You create a lot of noise. Please don't respond to this message. Peace.

  • Haha 1
  • Confused 1
2 hours ago, Andrey1970 said:

 

You boor and you are absolutely not competent.

 

Ah, yes. The straight go to for you guys, insult me. I'm definitely not competent... I mean most of the things that have come about in this community are almost all directly related to me introducing said ideas... but yeah.... You literally answered his "off topic" question that was about a config.plist setting and then told him it wasn't on topic. Grow up.

This is my first time using OpenCore, so please forgive any obvious errors.

 

I followed the (very complete) guide at https://dortania.github.io/OpenCore-Desktop-Guide and that answered a lot of questions. However, I am repeatedly not able to get past the error, shown in the attached image. It's the "[EB|#LOG:EXITBS:START]" error, which the guide makes several suggestions to remedy, none of which help me. There is no way to disable CFG-LOCK, so I have enabled AppleXcpmCfgLock and AppleCpuPmCfgLock.

 

My system is a Dell Optiplex 7050 Core i6-6500, with a AMD Radeon R5 340X video card. I've tried every USB port, on the machine, both USB2 and USB3, based on some comments that I have found, online. I've attached my boot log, and EFI folder, here, as well.

 

Thanks for any suggestions!

- Alex

 

 

IMG_0118.jpg

opencore-2020-05-25-032818.txt

EFI.zip

For those who might be interested. SSDT-SATA.aml, renames SAT0 to SATA only for OSX and leaves original names for other OSes(tested in OSX, Windows and Linux(have only couple live USB) .  You might need to edit the address, mine SAT0 is under 0x001F0002.

 

DefinitionBlock ("", "SSDT", 2, "HACK", "SATA", 0x00001000)
{
    External (_SB_.PCI0, DeviceObj)
    External (_SB_.PCI0.SAT0, DeviceObj)

    Scope (_SB.PCI0)
    {
        Scope (SAT0)
        {
            If (_OSI ("Darwin"))
            {
                Name (_STA, Zero)  // _STA: Status
            }
        }

        Device (SATA)
        {
            Name (_ADR, 0x001F0002)  // _ADR: Address
        }
    }
}

 

  • Like 2
This is my first time using OpenCore, so please forgive any obvious errors.

 

I followed the (very complete) guide at https://dortania.github.io/OpenCore-Desktop-Guide and that answered a lot of questions. However, I am repeatedly not able to get past the error, shown in the attached image. It's the "[EB|#LOG:EXITBS:START]" error, which the guide makes several suggestions to remedy, none of which help me. There is no way to disable CFG-LOCK, so I have enabled AppleXcpmCfgLock and AppleCpuPmCfgLock.

 

My system is a Dell Optiplex 7050 Core i6-6500, with a AMD Radeon R5 340X video card. I've tried every USB port, on the machine, both USB2 and USB3, based on some comments that I have found, online. I've attached my boot log, and EFI folder, here, as well.

 

Thanks for any suggestions!

- Alex

 

 

IMG_0118.thumb.jpg.89f6cacc031a6cc152099f68a18cf5b2.jpg

opencore-2020-05-25-032818.txt

EFI.zip

My Skylake desktop is also getting stuck here. I’ve unlocked cfg lock with modified grub shell which didn’t help.

 

 

Sent from my iPhone using Tapatalk

@arsradu I think @Andrey1970's comment did not detail why it is off-topic (though it is fairly obvious when you're used to the matter), so here's the thing... OpenCore allows you to add arbitrary properties of arbitrary type and value. This property may or may not be consumed by a kext. So to say, it has a syntax (config.plist declaration) to declare/add them.

However, this does not mean that any kext specific that somehow involves device properties is suddenly an OC topic. Your question does not to relate to any of that, it refers to the meaning (semantic) of specific properties, which should hopefully be obvious now that this does not depend on OC at all and hence is far out of scope.

 

While your question is an AppleALC topic, I'll still answer, but please do not reply further here - as far as I am aware, layout-id is prefered, alc-layout-id was introduced for internal compatibility reasons.

 

Also, kudos to those talking only static, your heroism almost solved a simple problem again.

 

EDIT: Corrected layout-id info, brain hung

Edited by Download-Fritz
  • Like 1
  • Thanks 1
This is my first time using OpenCore, so please forgive any obvious errors.  

I followed the (very complete) guide at https://dortania.github.io/OpenCore-Desktop-Guide and that answered a lot of questions. However, I am repeatedly not able to get past the error, shown in the attached image. It's the "[EB|#LOG:EXITBS:START]" error, which the guide makes several suggestions to remedy, none of which help me. There is no way to disable CFG-LOCK, so I have enabled AppleXcpmCfgLock and AppleCpuPmCfgLock.

 

My system is a Dell Optiplex 7050 Core i6-6500, with a AMD Radeon R5 340X video card. I've tried every USB port, on the machine, both USB2 and USB3, based on some comments that I have found, online. I've attached my boot log, and EFI folder, here, as well.

 

Thanks for any suggestions!

- Alex

 

 

IMG_0118.thumb.jpg.89f6cacc031a6cc152099f68a18cf5b2.jpg

opencore-2020-05-25-032818.txt

EFI.zip

 

Try setting

 

RebuildAppleMemoryMap to False

 

SetupVirtualMap to True

 

This is what worked for me.

 

 

Sent from my iPhone using Tapatalk

4 hours ago, Download-Fritz said:

@arsradu I think @Andrey1970's comment did not detail why it is off-topic (though it is fairly obvious when you're used to the matter), so here's the thing... OpenCore allows you to add arbitrary properties of arbitrary type and value. This property may or may not be consumed by a kext. So to say, it has a syntax (config.plist declaration) to declare/add them.

However, this does not mean that any kext specific that somehow involves device properties is suddenly an OC topic. Your question does not to relate to any of that, it refers to the meaning (semantic) of specific properties, which should hopefully be obvious now that this does not depend on OC at all and hence is far out of scope.

 

While your question is an AppleALC topic, I'll still answer, but please do not reply further here - as far as I am aware, alc-layout-id is prefered and was introduced for Mac compatibility (as they set their own ID themselves and one may want to override it using AppleALC).

 

Also, kudos to those talking only static, your heroism almost solved a simple problem again.

 

Probably is talking about the section in the documentation PDF that specifically talks about common properties. Remove that section if you don't want them to be related because otherwise that certainly seems related. Who knows though, guess I'm just talking static.... It's like you guys are running authoritarianism 101 playbook, lol.

×
×
  • Create New...