Issue 361: Sony SMBIOS TypeMemoryDevice is too small to fit necessary memory informations - Chameleon open source boot loader project.

Reported by Karas, Dec 2, 2013

It seems that on sony laptops the SMBMemoryDevice table (type 17) is 
too small to fit memory informations apart from bankLocator and 
memoryType. This causes System Information to not being able to read 
memory informations (displaying an error not being able to gather 
informations) and causes finder to crash when selecting "About 
This Mac" from the menu. This issues have been already posted 
here (http://forge.voodooprojects.org/p/chameleon/issues/357/) and 
here (http://forge.voodooprojects.org/p/chameleon/issues/122/).

I found that, during the creation of the new smbios from the 
original one the Memory Table was 21 bytes long instead of 27 
(according to the 2.1+ spec for SMBMemoryDevice in SMBIOS.h line 
325).

By forcing the new table to be 27 bytes long in the unction 
setSMBStruct (smbios.c) I found out that System Information was able 
to identify my memory and About This Mac no longer crashed.

I tested my modified boot with another user here (
http://forum.voodooprojects.org/index.php/topic,5922.0.html) and 
this worked for him too.

I can give you all the information you need if you think this is an 
issue with chameleon; what I think is happening and how I modified 
the code to make it work.

Thanks for you hard work.

- Karas

Comment 1 by ErmaC , Dec 3, 2013

Hi Karas.

Thx for investigate this.
Provide a diff file from the latest trunk.
We try to do a "large" TEST.

Fabio (ErmaC)

Comment 2 by Karas, Dec 3, 2013

Hi Fabio,
this is the diff for the 2 files i modified.

The first one is boot.h, i just added a custom boot option to 
enable/disable the new code:

Index: i386/boot2/boot.h
===================================================================
--- i386/boot2/boot.h	(revision 2271)
+++ i386/boot2/boot.h	(working copy)
@@ -94,6 +94,7 @@
 #define kForceHPET		"ForceHPET"		/* pci_setup.c */
 #define kUseMemDetect		"UseMemDetect"		/* platform.c */
 #define kSMBIOSdefaults		"SMBIOSdefaults"	/* 
smbios_patcher.c */
+#define kMemFullInfo		"ForceFullMemInfo"	/* smbios.c */
 #define kUSBBusFix		"USBBusFix"		/* usb.c */
 #define kEHCIacquire		"EHCIacquire"		/* usb.c */
 #define kUHCIreset		"UHCIreset"		/* usb.c */


The second one is smbios.c, apart the check for the previous option 
the modification itself is just 2 lines long:

Index: i386/libsaio/smbios.c
===================================================================
--- i386/libsaio/smbios.c	(revision 2271)
+++ i386/libsaio/smbios.c	(working copy)
@@ -628,6 +628,16 @@
 	uint8_t *ptr;
 	SMBWord structSize;
 	int i;
+    
+    bool forceFullMemInfo = false;
+    
+    if (structPtr->orig->type == kSMBTypeMemoryDevice)
+    {
+        getBoolForKey(kMemFullInfo, &forceFullMemInfo, 
&bootInfo->chameleonConfig);
+        
+        if (forceFullMemInfo)
+            structPtr->orig->length = 27;
+    }
 
 	stringIndex = 1;
 	stringsSize = 0;



My guess is that the original apple smbios is supposed to have a 2.3 
spec MemoryDevice (as defined in SMBIOS.h, line 338), so when it 
reads the smbios at runtime it crashes due its wrong dimension. I 
tested this on a friend pc (samsung) and its MemoryDevice is indeed 
27 bytes long (and thus he is not affected by this problem).

I also think (but i'm not sure) that chameleon actually writes (or 
try to write) the memory information stored in smbios.plist (or the 
memory infos gathered at runtime during boot) into smbios (smbios.c, 
funcion setSMBValue, lines 469-474) because the string value is 
correctly passed to the function setSMBStringForField at line 530, 
but due to the short size of the MemoryDevice these value are 
written over the actual table and in the next one, but they are then 
overwritten by the next table in smbion.

This is a wild guess of course, you have a lot more knowledge than 
me about this, i just wanted to share my thoughts :)

- Karas

Comment 3 by ErmaC , Dec 5, 2013

Due to the nature of this workaround I will implement it "AS 
IS".
The BOOLEAN nature of the flag don't mess the code.

thx

Fabio

Status: Fixed