Hi,

habe hier ein MBP2,2(Nov 2006) mit Core2Duo und einer Ati X1600. Das Book sollte doch eigentlich im 64Bit-Modus starten können. Tut es aber nicht. Gibt es, ausser der CPU noch andere Bedingungen, die erfüllt sein müssen? Nicht, dass ich es wirklich bräuchte. Aber es interessiert mich, warum es nicht funktioniert.

wahrscheinlich weil dein EFI nicht 64 bit ist.

ein Screenshot von einem MacBook Pro Mid 2009 (ach ja, der Screenshot wurde gemacht unter Mac OS X 10.5.8!!!):

Irgendwo lass ich, dass das EFI dabei keine Rolle spielen soll. Na mal abwarten, was sonst noch Ursache sein kann.

Ich habe auch ein Macbook pro (2,16)
Habe die EFI-Treiberversion: 01.00.158

Würde auch gerne wissen, ob es 64bit fähig ist.
Könnt Ihr mir bitte mal sagen wie das Tool heißt mit dem man das testen kann?

Was limitiert hierbei eigentlich die 64bit, das Flash-EEPROM oder die Programmierung?

Gibt es eine zuverlässige Übersicht, von Apple beispielsweise, in welchem Macbook welches EFI verwendet wurde?

Hallo maggi,

gibt´s hier:

elcaradura
Genau das will ich ja rausfinden. Wo ist die Blockade versteckt und kann man sie umgehen.

Ob das EFI 32 oder 64 hat, ist egal. Es sind eventuell noch nicht alle Kernel-Erweiterungen (Treiber) 64-Bit für die betroffenen Modelle. Ein Prozeß kann nur Code laden mit der gleichen Bittigkeit. Der Kernel ist auch ein Prozeß und kann in 64 Bit also nur 64-Bit-Kexts laden. Im 32-Bit-Mode kann der Kernel alle 32-Bit-Kexts laden.

Beispiel aus 10.5.8 (Snow Leopard ist noch in der Post für mich):

32-Bit-Intel und 32-Bit-PPC sieht man hier.

MacMark

Und welchen Einfluss haben nun die Kexts auf Programme? Was passiert eigentlich, wenn in Zukunft die Extensions in 64-Bit vorliegen? Diese können doch nicht vom 32-Bit-Efi geladen werden, oder?

Theoretisch ist es zumindest möglich das EFI neu zu flashen oder den Speicherbaustein zu wechseln. Allerdings wird das nicht ohne sein, von der nötigen handwerklichen Gabe ganz zu schweigen.
Ich habe bisher kein Dokument gefunden was die verbauten Flash-EEPROMS näher beschreibt als deren Kapazität 2MB/4MB. Zu klären wäre ohnehin, ob bspw. die EFI-Version für ein MacBook X,Y auch für das MacBook X-n,Y-n funktionieren würde, sollte man den Speicherbaustein erfolgreich wechseln können.
Ich verstehe nach wie vor das EFI als erweitertes BIOS und die BIOS-Files waren, wenn auch standardisiert, auf das gegebene Motherboard/Logic Board zugeschnitten. Es kann also sein, dass der Austausch schon daran scheitert.

Wenn ich nun das nachfolgende Bild sehe, sind es nur ein paar Extensions, die nicht in 64Bit vorliegen. Der Rest scheint in 64Bit vorzuliegen. Ich kann mir aber nicht die Maus(bluetooth) als Grund vorstellen.

Kiwi-Bodo

Hast du auch die MS Bluetooth Notebook Mouse 5000?

elcaradura
Ja. Die ist recht brauchbar. Läuft bei mir mit Akkus.

MacMark
Soweit verstanden. Aber bei den paar Extensions(siehe Bild), die nicht 64Bit sind, frage ich mich, wo ist er, der Blockierer ...

Bin auch damit bis auf das hakelige Scrollrad ganz zufrieden. Unter OS X funktioniert sie auch einwandfrei - Probleme gab es bisher nur unter Windows.
Machen die Akkus Sinn? Wie lange hält eine Ladung?

(Passt jetzt überhaupt nicht zum Thema, du kannst also gerne auch mailen.)

Nach ein wenig suchen im Netz scheint Airport das Problem zu sein. Ich werde ihn mal deaktivieren und dann neustarten. Mal sehen, was passiert.

Ein Programm benötigt eventuell eine Funktion, die eine bestimmte Kext ermöglicht. Wenn alle Kexts in 64 Bit vorliegen, können sie vom 64er-Kernel verwendet werden. Jedes EFI kann jeden Kernel laden. Es kann aber so programmiert sein, daß es absichtlich nur den 32er Kernel lädt, damit der Kernel alle Kexts nutzen kann, um den Benutzer in der Übergängszeit bis alles verfügbar ist, nicht einzuschränken.

MacMark
So, anbei noch ein Bild. Interessanterweise wird eine "AppleIntelYonahProfile.kext" geladen. Eigentlich sollte es die "AppleIntelMeromProfile.kext" sein. Hier scheint das Problem zu liegen. Der Yonah(CoreDuo) ist der 32Bitter, der Merom(Core2Duo) ist der 64Bitter. Und letzterer ist hier im Book.

sehr interessanter thread!!! wieder was dazu gelernt!

Versuch doch mal die Yonah/Nehalem/Penryn-Profile zu löschen, Vielleicht wird dann Merom genommen?

mal ne frage...

soweit ich nun hier im forum mitbekommen habe sind alle core 2 duo prozessoren 64-bit fähig.

ich habe einen macbook late 2007, habe auch das oben angegebene tool benutzt. allerdings komm ich nicht auf die 64 bit (im systemprofiler steht folgendes: 64-Bit-Kernel and -Erweiterungen: Nein)

habe auch schon beim start 6 und 4 gedrückt gehalten, klappt auch nicht.
Ich hab so langsam das gefühl, dass es garnicht unterstützt wird...

wenn das wirklich so ist, werde ich meins verkaufen und dann wieder ganz auf windows wechseln, habe es langsam satt-habe damals extra auf das 64bit mbp gewartet und dann soll es offiziell nicht unterstützt werden

schaut euch doch mal den folgenden link an...da findet man eigentlich alle infos/antworten zum thema 64-bit. ich hab jedenfalls keine fragen mehr

http://www.ahatfullofsky.comuv.com/Deutsch/Programme/SMS/SMS.html

Ergo eine reine Update-Geschichte. Aber meinst du, dass Apple dieses Update nachliefert? Alleine die integrierten Grafikkarten GMA 950 und GMA X3100 bräuchten ein Treiberupdate. Das macht die Geschichte doch sehr unwahrscheinlich.
Dann werden wohl in geraumer Zukunft auch so manches Programm vielleicht nicht mehr auf den ersten C2D-MacBooks laufen.
Alleine auf Adobe CS5 oder Adobe CS6 bin ich gespannt, ob diese dann noch auf den 32bit-Kext laufen.

Aber alles reine Spekulation... Danke für die Infos.

zesniert: Alleine deshalb nun das MBP zu verkaufen halte ich etwas für verfrüht. Bis dieser Umstand greift wird man wohl sagen, dass auch die Stunde für die angegrauten ersten C2D-MB/P's geschlagen hat.

Hier werden einige Fehlinformationen verbreitet. Richtig ist Folgendes:

- Ob ein Computer ein 32-Bit-EFI oder ein 64-Bit-EFI hat, spielt für den 64-Bit-Betrieb von Snow Leopard überhaupt keine Rolle.
- Wenn ein 64-Bit-Prozessor vorhanden ist, laufen alle Programme, die 64 Bit unterstützen können, automatisch im 64-Bit-Modus.
- Eine Ausnahme ist der Systemkern (Kernel): Im Moment empfiehlt Apple nur auf den letzten beiden Generationen des Xserve, den Kernel zum jetzigen Entwicklungsstand bereits im 64 Bit-Modus laufen zu lassen. Auf allen anderen Rechnern läuft der Kernel standardmäßig im 32-Bit-Modus. Grund dafür ist, dass der Kernel exakt zu den vorhandenen Treibern (Kernel-Erweiterungen) passen muss. Viele Treiber - die meisten von Drittanbietern, einige aber auch von Apple - liegen im Moment noch nicht in einer 64-Bit-Version vor. Teilweise geht das auch noch gar nicht, da der 64-Bit-Kernel im Gegensatz zur 32-Bit-Version noch einige Einschränkungen aufweist und einige Treiber Funktionen brauchen, die im 64-Bit-Kern zurzeit nicht zur Verfügung stehen. Das wird sich (hoffentlich) in den nächsten Monaten bis Jahren ändern.
- Bei bestimmten Modellserien kann man Snow Leopard durch einen manuellen Eingriff dazu zwingen, auch den Kern im 64-Bit-Modus laufen zu lassen. Dies gilt im Moment aber noch nicht für alle 64-Bit-fähigen Modellserien. Das hat NICHTS damit zu tun, welche Treiber im Moment im System vorliegen. Fehlt ein 64-Bit-Treiber, dann fällt der zugehörige Hardwarebaustein eben einfach aus.
- Vereinfacht gesagt ist der Kernel zwar das wichtigste "Programm" in Mac OS X, es ist aber sozusagen nur eins von vielen. In vielen Konfigurationen bringt der Einsatz des 64-Bit-Kerns mehr Nachteile als Vorteile.

Anwendungsprogrammme arbeiten typischerweise nicht direkt mit Kexts. Die Anwendungs-APIs sind schon länger 32- und 64-bittig.
Welche sind das? Beschreibt Apple das irgendwo?

MacMark: Wieder hinzugelernt. Merci!

@ Marcel Bresnik: Danke für Deine kurze Erklärung.

Nachtrag: Auf meinem Macbook wird korrekterweise das Penryn-Profil geladen. 64-bit geht trotzdem nicht (obwohl das EFI auch ein 64er ist)

Ich habe folgendes gelesen:
Dies ist z.B. bei meinem MacPro 1.1 der fall. bootet im 32bit SL, rennt aber 64bit Programme.

Nicht nur typischerweise nicht. Das ist technisch gar nicht möglich, da Kexts Schnittstellen verwenden, die im "Userland" gar nicht zur Verfügung stehen, und möglicherweise auch privilegierte Assembler-Befehle nutzen, die in Anwenderprogrammen nicht erlaubt sind.

Ein Anwendungsprogramm kann Kexts nur indirekt nutzen, indem der Kernel die Erweiterung lädt und die Erweiterung dann z.B. über die IORegistry oder sysctl()-Aufrufe Kommunikationskanäle in das Userland schaltet.

Das sind alle Funktionen, die früher über com.apple.kernel*-Bibliotheken, bzw. über com.apple.kpi.unsupported zur Verfügung standen. Apple behauptet, für all diese Funktionen gäbe es Ersatz und private APIs gingen niemanden etwas an, aber in der Praxis stellt sich natürlich heraus, dass das nicht stimmt, Funktionalität fehlt und sich dadurch Probleme ergeben.

Für einen meiner eigenen Treiber bräuchte ich z.B. die Kernel-Funktion cpu_number(), die in fast allen Unix-Systemen vorhanden ist, im 32-Bit-Kernel auch zur Verfügung steht, im 64-Bit-Kernel jedoch nicht mehr erreicht werden kann.

Ein weiteres Problem besteht darin, dass man als Behelf verschiedene Funktionen auch nicht mehr selbst nachbauen kann, denn im Moment steht der xnu-Quelltext für Snow Leopard (noch?) nicht zur Verfügung, so dass notwendiges Hintergrundwissen über bestimmte Abläufe nicht mehr vorliegt.

Man sieht schon seit Jahren an den Treibern von Drittanbieter-ATA-Schnittstellen, z.B. von Sonnet oder FirmTek, dass Apples Vorgehen hier einige Probleme macht, denn die Treiber sind auf dem technischen Stand von Panther stehengeblieben. (In Panther war der AppleATA-Treiber noch Open Source und fremde Anbieter konnten das Know-How nutzen.) Neue Entwicklungen, wie z.B. SATA-Treiber nach AHCI-Standard, die sich nahtlos in Mac OS X integrieren, sind mit Snow Leopard für Dritte so gut wie nicht mehr realisierbar.

Siehe Kernel Extensions Release Notes for Snow Leopard:

Marcel Bresink
Danke, Doc. Wieder was gelernt. MTN wird noch ne richtige Bildungsseite ...

Jetzt läd mein Book übrigens das "MeromProfile" ... Ich hatte Airport komplett deaktiviert und neugestartet. Dann Airport wieder aktiviert.

"Die Wege der Bytes sind unergründlich ...!"

Sehr interessante .kext gefunden. Musste ein wenig schmunzeln.