<div dir="ltr">Hello Tank,<div><br></div><div>I am reading your messages and I am thinking, since the use case you are presenting here does not make any sense to me.</div><div><br></div><div>You are managing <span style="font-size:12.8px">DTS (Digital Thermal Sensor), this is something inherently integrated on silicon die (I think per core), and there is no need to manage it from SMM prospective. The gradient of Temperature is slow, you can start checking it from ramstage every minimum 100ms, which is anyhow great overkill (minimum should be 1000ms), in my opinion. Except if you are not putting/on purpose missing heatsink on the top of CPU and experimenting how long the CPU can work.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Yes, MSRs </span><font color="#500050"><span style="font-size:12.8px">0x19B/0x19C are General Purpose MSRs (presented in all CORE and ATOM families), and they are accessible from anywhere, anytime, </span></font></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">I am not sure, but there is also built-in HW T monitor which, while detecting ~5C below T junction, issues automatically PROCHOT# active low, which shutdowns all cores and platform to S5 state (PROCHOT# signal should go to EC or PMIC as well).</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">PROCHOT# : <a href="https://www.manualslib.com/manual/407246/Intel-Celeron-Processor-E3000-Thermal-And-Mechanical-Design.html?page=32">https://www.manualslib.com/manual/407246/Intel-Celeron-Processor-E3000-Thermal-And-Mechanical-Design.html?page=32</a><br></span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Other that that, in Linux you can have a thermal application (user space) which will every second scan DTS, and show you the graphical value (I guess, INTEL for this has so-called TAT tool (also works as test load balancer for cores and integrated GFX), but there are also other apps for monitoring as well).</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Why you need to monitor DTS in SMM, that is my question (seems completely unnecessary)? What for? You are NOT going to apply turbo mode in Coreboot, as well as play performance boost with TPD1 to TDP2 (not wise at all to do these boosts in BSPs)?!</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Thank you,</span></div><div><span style="font-size:12.8px">Zoran</span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 5, 2017 at 6:20 AM, Tang Tank <span dir="ltr"><<a href="mailto:js_nj_tanktang@outlook.com" target="_blank">js_nj_tanktang@outlook.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Aaron,<br>
<br>
Yes, I do this as you say.<br>
Add a ID like CBMEM_ID_MP_SMM(cbmem_add (CBMEM_ID_MP_SMM, sync_data_size)), and pass addr to smm_runtime when smm relocation.<br>
It seems ok to install and boot win10/boot ubuntu, but it will hang when install ubuntu.<br>
I have none debugging methods for this issue. So I hope to define a static variable to do this and have a try.<br>
<br>
Thanks<br>
<span class=""> Tank<br>
<br>
发件人: Aaron Durbin <<a href="mailto:adurbin@google.com">adurbin@google.com</a>><br>
</span>发送时间: 2017年1月4日 19:47<br>
收件人: Tang Tank<br>
抄送: Nico Huber; Zoran Stojsavljevic; coreboot<br>
主题: Re: 答复: 答复: [coreboot] logical error for smm hander in coreboot.<br>
<div class="HOEnZb"><div class="h5"> <br>
On Wed, Jan 4, 2017 at 7:12 PM, Tang Tank <<a href="mailto:js_nj_tanktang@outlook.com">js_nj_tanktang@outlook.com</a>> wrote:<br>
> Hi Nico,<br>
><br>
> The MSRs can access and modify at any time. But DTS feature need to done in smm.<br>
> I need to check this msr 0x19b/0x19c and set the trigger temperature dynamically in smm.<br>
> I will set a software gpe to notify that the _tmp method vaule in the thermal zone has been changed when a dts smi occured.<br>
> And then OS will change the speed of fan(active temperature), power and freq of cpus (passive temperature) or shutdown (critial temperature).<br>
> So do you know the way to define a static variable which can been used under smm stage and ram stage?<br>
> Now I reserved a fixed memory addr in ramstage, hard code the pointer to the addr in smi hander and complete the dts feature in win10 successfully.<br>
> But I found that this will cause a hang when boot linux OSs such as ubuntu.<br>
<br>
You can't just use a fixed memory address w/o reserving the memory<br>
from the OS. If you need to read and write this memory from SMM and<br>
ASL I suggest you add the memory to cbmem which will reserve it from<br>
the OS. From there you can reference the memory in ASL and from SMM<br>
(once both are in told about the memory address).<br>
<br>
><br>
><br>
> Thanks<br>
> Tank<br>
><br>
> 发件人: Nico Huber <<a href="mailto:nico.huber@secunet.com">nico.huber@secunet.com</a>><br>
> 发送时间: 2017年1月4日 7:37<br>
> 收件人: Tang Tank; Aaron Durbin; Zoran Stojsavljevic<br>
> 抄送: coreboot<br>
> 主题: Re: 答复: [coreboot] logical error for smm hander in coreboot.<br>
><br>
> Hi Tank,<br>
><br>
> On 04.01.2017 02:39, Tang Tank wrote:<br>
>> Hi Nico , Aaron, Zoran,<br>
>><br>
>> Thank you for your help!<br>
>> Smi_sts will been cleared after southbridge_smi_handler runs.<br>
>> I am working for intel apollake now, need to do a thermal feature named DTS(Digital Thermal Sensor).<br>
>> This need to check and modify MSR in smm for every core .<br>
><br>
> is this MSR only accessible from SMM? or where does the requirement to<br>
> do it in SMM come from? It sounds like something that's better done in<br>
> the OS or ACPI.<br>
><br>
> Nico<br>
><br>
>> And when I add a mechanism to sync up bsp and aps like below struct , I found that I can't define and use the same static variable in ramstage and smmstage.<br>
>> How can I do this?<br>
>><br>
>> typedef struct {<br>
>> spin_lock <wbr> busy;<br>
>> volatile ap_procedure procedure;<br>
>> volatile void *parameter;<br>
>> volatile u32 run;<br>
>> volatile bool present;<br>
>> } smm_cpu_data;<br>
>><br>
>> typedef struct {<br>
>> smm_cpu_data *cpu_data;<br>
>> volatile u8 cpu_count;<br>
>> volatile u32 bsp_index; //we will assusme index 0 as bsp<br>
>> volatile bool all_cores_is_sync;<br>
>> volatile u64 time_out_ticker;<br>
>> } smm_mp_sync_data;<br>
>><br>
>> Thanks,<br>
>> Tank<br>
>><br>
>> 发件人: Aaron Durbin <<a href="mailto:adurbin@google.com">adurbin@google.com</a>><br>
>> 发送时间: 2017年1月3日 7:23<br>
>> 收件人: Nico Huber<br>
>> 抄送: Tang Tank; coreboot<br>
>> 主题: Re: [coreboot] logical error for smm hander in coreboot.<br>
>><br>
>> On Tue, Jan 3, 2017 at 6:37 AM, Nico Huber <<a href="mailto:nico.huber@secunet.com">nico.huber@secunet.com</a>> wrote:<br>
>>> Hi Tank,<br>
>>><br>
>>> On 03.01.2017 04:20, Tang Tank wrote:<br>
>>>><br>
>>>> Hi all,<br>
>>>><br>
>>>><br>
>>>> For smm handler (func smm_handler_start) in coreboot/src/cpu/x86/smm/smm_<wbr>module_handler.c,<br>
>>>> there may be a logical error.<br>
>>>><br>
>>>> If I have 4 cores in my mainboard in the following special conditions:<br>
>>>> 1. core0 run into smm_handler_start and smi_handler_status will be SMI_LOCKED.<br>
>>>> 2. core1/2 run into smm_handler_start and pause since smi_handler_status is locked.<br>
>>>> 3. core0 release smi_handler_status and then core4 run into smm_handler_start, it will do<br>
>>>> southbridge_smi_handler again.<br>
>>><br>
>>> looking at the code, I too see that possible race. But...<br>
>>><br>
>>>><br>
>>>> So is there have a reliable way of doing smm multi processors services in coreboot?<br>
>>><br>
>>> ...IMO, this isn't unreliable. After the first run of a cpu/northbridge<br>
>>> /southbridge_smi_handler() function, the cause of the SMI should be<br>
>>> handled and thus the second run should do nothing (but checking for the<br>
>>> SMI's cause).<br>
>>><br>
>>> Does that help? I wasn't sure if I got your question right.<br>
>><br>
>><br>
>> Or you have to wait for all the CPUs to check in before dealing with<br>
>> the SMM handler logic. One would also have to deal with SMIs that were<br>
>> not broadcast since the other CPUs would never check in.<br>
>><br>
>>><br>
>>> Nico<br>
>>><br>
>>><br>
>>> --<br>
>>> coreboot mailing list: <a href="mailto:coreboot@coreboot.org">coreboot@coreboot.org</a><br>
>>> <a href="https://www.coreboot.org/mailman/listinfo/coreboot" rel="noreferrer" target="_blank">https://www.coreboot.org/<wbr>mailman/listinfo/coreboot</a><br>
<br>
<br>
coreboot Info Page<br>
<a href="http://www.coreboot.org" rel="noreferrer" target="_blank">www.coreboot.org</a><br>
coreboot project mailing list. To see the collection of prior postings to the list, visit the coreboot Archives. Using coreboot<br>
<br>
><br>
><br>
> coreboot Info Page<br>
> <a href="http://www.coreboot.org" rel="noreferrer" target="_blank">www.coreboot.org</a><br>
> coreboot project mailing list. To see the collection of prior postings to the list, visit the coreboot Archives. Using coreboot<br>
><br>
>><br>
>><br>
>> coreboot Info Page<br>
>> <a href="http://www.coreboot.org" rel="noreferrer" target="_blank">www.coreboot.org</a><br>
>> coreboot project mailing list. To see the collection of prior postings to the list, visit the coreboot Archives. Using coreboot<br>
><br>
</div></div></blockquote></div><br></div>