[Sound-open-firmware] [PATCH] arch: xtensa: set SRAM window error codes during bootloader

Mon Jun 11 16:17:18 CEST 2018

>-----Original Message-----
>From: sound-open-firmware-bounces at alsa-project.org [mailto:sound-open-
>firmware-bounces at alsa-project.org] On Behalf Of Pan, Xiuli
>Sent: Monday, June 11, 2018 5:52 PM
>To: Keyon Jie <yang.jie at linux.intel.com>; sound-open-firmware at alsa-
>project.org
>Subject: Re: [Sound-open-firmware] [PATCH] arch: xtensa: set SRAM window
>error codes during bootloader
>
>
>
>On 6/11/2018 16:38, Keyon Jie wrote:
>>
>>
>> On 2018年06月11日 16:29, Pan, Xiuli wrote:
>>>
>>>
>>> On 6/11/2018 15:58, Lauda, Tomasz wrote:
>>>> FW sets MW0 to different address than ROM We are setting status 0x05
>>>> from bootloader, so it's the correct assumption, that ROM jumped out
>>>> to FW correctly.
>>> So could we disable the MW0 setting in the boot loader? This seems to
>>> broke the status check as we want to check the ROM code.
>>>
>>> And BTW, I checked the memory window data and found they are fulled
>>> with some data that I can find in the rodata. Should this happen?
>>> If the memory data can be some none zero value, i suggest that we add
>>> a memset for the memory we used for memory windows
>>
>> We previously memset all MW datas to 0s at MW setup, except those
>> registers reserved for ROM status, does anything of that changed?
>>
>I tried to add memset in platform_memory_windows_init, but there still some
>unknown data.
>After comparing the data, I found that the memory in the MW3 (from file
>/sys/kernel/debug/sof/etrace) is the exactly the same data in the sof-apl.ri binary
>from offset 0x38000 to 0x3a000.
>I could not find any related with these two values, but there are two pages of the
>data is exactly same. We must have something wrong with memory settings.
>Either memory window or the memory mapping.
>Anyone have any idea?

Since DMA trace works, can you use DMA trace to dump this MW3 region at different FW initial stage, to see when it is changed?
e.g. at boot loader stage, or platform initial stage, or after FW_READY?

Thanks,
~Keyon

>
>
>HEXDUMP for /sys/kernel/debug/sof/etrace
>
>0000000 f99f ff17 7557 019e 6ccc fd7d b651 03a3
>0000010 7d57 fae3 c582 071f a85a f5e4 ac82 0f2e
>0000020 7e76 e584 5b06 513e 5b06 513e 7e76 e584
>0000030 ac82 0f2e a85a f5e4 c582 071f 7d57 fae3
>0000040 b651 03a3 6ccc fd7d 7557 019e f99f ff17
>0000050 bae7 0055 cf09 001e d41d ff85 e0f6 00bf
>0000060 2f5e ff0d 78f7 0115 e827 fed5 bf27 0132
>0000070 a101 fece c9e6 0127 4ac4 fee8 b78a 0102
>0000080 ba22 ff15 b0da 00cf dde1 ff4b 9a5b 0098
>0000090 0fc4 ff82 d063 0064 4196 ffb2 16d8 0039
>00000a0 edf4 ffd8 c7d9 0017 cc3f fff4 3993 0001
>00000b0 55cd 0006 4871 fff4 3257 000f ee1f ffee
>00000c0 a32a 0011 cef0 ffee 019f 0010 ac0c fff1
>00000d0 5ed0 000c b043 fff5 4ac8 0008 9548 fff9
>00000e0 c1aa 0004 a5fe fffc 378c 0002 a739 fffe
>00000f0 26e6 0000 2d62 0000 3301 ffff ccc8 0001
>0000100 bec0 fffc 3d0a 0005 30e5 fff8 00c7 000b
>
>HEXDUMP for sof-apl.ri
>
>0038000 f99f ff17 7557 019e 6ccc fd7d b651 03a3
>0038010 7d57 fae3 c582 071f a85a f5e4 ac82 0f2e
>0038020 7e76 e584 5b06 513e 5b06 513e 7e76 e584
>0038030 ac82 0f2e a85a f5e4 c582 071f 7d57 fae3
>0038040 b651 03a3 6ccc fd7d 7557 019e f99f ff17
>0038050 bae7 0055 cf09 001e d41d ff85 e0f6 00bf
>0038060 2f5e ff0d 78f7 0115 e827 fed5 bf27 0132
>0038070 a101 fece c9e6 0127 4ac4 fee8 b78a 0102
>0038080 ba22 ff15 b0da 00cf dde1 ff4b 9a5b 0098
>0038090 0fc4 ff82 d063 0064 4196 ffb2 16d8 0039
>00380a0 edf4 ffd8 c7d9 0017 cc3f fff4 3993 0001
>00380b0 55cd 0006 4871 fff4 3257 000f ee1f ffee
>00380c0 a32a 0011 cef0 ffee 019f 0010 ac0c fff1
>00380d0 5ed0 000c b043 fff5 4ac8 0008 9548 fff9
>00380e0 c1aa 0004 a5fe fffc 378c 0002 a739 fffe
>00380f0 26e6 0000 2d62 0000 3301 ffff ccc8 0001
>0038100 bec0 fffc 3d0a 0005 30e5 fff8 00c7 000b
>
>
>
>> Thanks,
>> ~Keyon
>>
>>>
>>> Thanks
>>> Xiuli
>>>>
>>>> Tomek
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: sound-open-firmware-bounces at alsa-project.org
>>>> [mailto:sound-open-firmware-bounces at alsa-project.org] On Behalf Of
>>>> Pan, Xiuli
>>>> Sent: Monday, June 11, 2018 7:11 AM
>>>> To: Liam Girdwood <liam.r.girdwood at linux.intel.com>;
>>>> sound-open-firmware at alsa-project.org
>>>> Cc: Kamil Kulesza <kamil.kulesza at linux.intel.com>
>>>> Subject: Re: [Sound-open-firmware] [PATCH] arch: xtensa: set SRAM
>>>> window error codes during bootloader
>>>>
>>>>
>>>>
>>>> On 6/9/2018 03:06, Liam Girdwood wrote:
>>>>> On Fri, 2018-06-08 at 19:42 +0100, Liam Girdwood wrote:
>>>>>> From: Kamil Kulesza <kamil.kulesza at linux.intel.com>
>>>>>>
>>>>>> Set status (0x05) and error (0x00) code in Memory Window 0 when
>>>>>> the bootloader starts.
>>>>>> boot_entry.S - set status (0x05) and error (0x00) code before wnd0
>>>>>> reprogram platform/memory.h - increase bootloader size
>>>>>>
>>>>>> Signed-off-by: Kamil Kulesza <kamil.kulesza at linux.intel.com>
>>>>>> ---
>>>>>>    src/arch/xtensa/boot_entry.S                  | 22
>>>>>> +++++++++++++++++++
>>>>>>    .../apollolake/include/platform/memory.h      |  2 +-
>>>>>>    .../cannonlake/include/platform/memory.h      |  2 +-
>>>>>>    3 files changed, 24 insertions(+), 2 deletions(-)
>>>>>>
>>>>>>
>>>> This patch seems to be a workaround for the firmware boot up. The
>>>> status
>>>> (0x05) should be set by the rom.
>>>> With the rmbox and dump data from status registers. It seems all
>>>> memory window is fulled with rodata of the firmware. I think there
>>>> is some potential bugs for memory window.
>>>> If this is not a bug maybe we need to add memset for memory windows.
>>>>
>>>> Thanks
>>>> Xiuli
>>>>
>>>>> Applied.
>>>>>
>>>>> Thanks
>>>>>
>>>>> Liam
>>>>> _______________________________________________
>>>>> Sound-open-firmware mailing list
>>>>> Sound-open-firmware at alsa-project.org
>>>>> http://mailman.alsa-project.org/mailman/listinfo/sound-open-firmwar
>>>>> e
>>>> _______________________________________________
>>>> Sound-open-firmware mailing list
>>>> Sound-open-firmware at alsa-project.org
>>>> http://mailman.alsa-project.org/mailman/listinfo/sound-open-firmware
>>>> --------------------------------------------------------------------
>>>>
>>>> Intel Technology Poland sp. z o.o.
>>>> ul. Slowackiego 173 | 80-298 Gdansk | Sad Rejonowy Gdansk Polnoc |
>>>> VII Wydzial Gospodarczy Krajowego Rejestru Sadowego - KRS 101882 |
>>>> NIP 957-07-52-316 | Kapital zakladowy 200.000 PLN.
>>>>
>>>> Ta wiadomosc wraz z zalacznikami jest przeznaczona dla okreslonego
>>>> adresata i moze zawierac informacje poufne. W razie przypadkowego
>>>> otrzymania tej wiadomosci, prosimy o powiadomienie nadawcy oraz
>>>> trwale jej usuniecie; jakiekolwiek przegladanie lub
>>>> rozpowszechnianie jest zabronione.
>>>> This e-mail and any attachments may contain confidential material
>>>> for the sole use of the intended recipient(s). If you are not the
>>>> intended recipient, please contact the sender and delete all copies;
>>>> any review or distribution by others is strictly prohibited.
>>>>
>>>> _______________________________________________
>>>> Sound-open-firmware mailing list
>>>> Sound-open-firmware at alsa-project.org
>>>> http://mailman.alsa-project.org/mailman/listinfo/sound-open-firmware
>>>
>>> _______________________________________________
>>> Sound-open-firmware mailing list
>>> Sound-open-firmware at alsa-project.org
>>> http://mailman.alsa-project.org/mailman/listinfo/sound-open-firmware
>>>
>> _______________________________________________
>> Sound-open-firmware mailing list
>> Sound-open-firmware at alsa-project.org
>> http://mailman.alsa-project.org/mailman/listinfo/sound-open-firmware
>
>_______________________________________________
>Sound-open-firmware mailing list
>Sound-open-firmware at alsa-project.org
>http://mailman.alsa-project.org/mailman/listinfo/sound-open-firmware