[Sound-open-firmware] [PATCH] platform: extract common API from platform headers.
From: Marcin Maka marcin.maka@linux.intel.com
Common platform API separated to avoid duplicated declarations and group public functions to be implemented by every platform.
Signed-off-by: Marcin Maka marcin.maka@linux.intel.com --- src/include/sof/panic.h | 4 +- src/include/sof/platform.h | 60 +++++++++++++++++++ .../apollolake/include/platform/platform.h | 15 ++--- .../baytrail/include/platform/platform.h | 16 ++--- .../cannonlake/include/platform/platform.h | 16 ++--- .../haswell/include/platform/platform.h | 16 ++--- 6 files changed, 83 insertions(+), 44 deletions(-) create mode 100644 src/include/sof/platform.h
diff --git a/src/include/sof/panic.h b/src/include/sof/panic.h index 3efb659..7c19939 100644 --- a/src/include/sof/panic.h +++ b/src/include/sof/panic.h @@ -58,9 +58,7 @@ static inline void panic_rewind(uint32_t p, uint32_t stack_rewind_frames) p = dump_stack(p, ext_offset, stack_rewind_frames, count * sizeof(uint32_t));
- /* TODO: send IPC oops message to host */ - - /* panic */ + /* panic - send IPC oops message to host */ platform_panic(p);
/* flush last trace messages */ diff --git a/src/include/sof/platform.h b/src/include/sof/platform.h new file mode 100644 index 0000000..8b228ee --- /dev/null +++ b/src/include/sof/platform.h @@ -0,0 +1,60 @@ +/* + * Copyright (c) 2018, Intel Corporation + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions are met: + * * Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * * Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * * Neither the name of the Intel Corporation nor the + * names of its contributors may be used to endorse or promote products + * derived from this software without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" + * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE + * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR + * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF + * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS + * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN + * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) + * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE + * POSSIBILITY OF SUCH DAMAGE. + * + * Author: Marcin Maka marcin.maka@linux.intel.com + */ + +#ifndef __INCLUDE_SOF_PLATFORM_H__ +#define __INCLUDE_SOF_PLATFORM_H__ + +#include <sof/sof.h> + +/* + * APIs declared here are defined for every platform. + */ + +/** + * \brief Platform specific implementation of the On Boot Complete handler. + * \param[in] boot_message Boot status code. + * \return 0 if successful, error code otherwise. + */ +int platform_boot_complete(uint32_t boot_message); + +/** + * \brief Platform initialization entry, called during FW initialization. + * \param[in] sof Context. + * \return 0 if successful, error code otherwise. + */ +int platform_init(struct sof *sof); + +/** + * \brief Called by the panic handler. + * \param[in] p Panic cause, one of SOF_IPC_PANIC_... codes. + */ +static inline void platform_panic(uint32_t p); + +#endif diff --git a/src/platform/apollolake/include/platform/platform.h b/src/platform/apollolake/include/platform/platform.h index 6d51752..1321f1f 100644 --- a/src/platform/apollolake/include/platform/platform.h +++ b/src/platform/apollolake/include/platform/platform.h @@ -33,6 +33,7 @@ #ifndef __PLATFORM_PLATFORM_H__ #define __PLATFORM_PLATFORM_H__
+#include <sof/platform.h> #include <platform/platcfg.h> #include <platform/shim.h> #include <platform/interrupt.h> @@ -120,11 +121,11 @@ struct sof; #define PLATFORM_NUM_SSP 6
/* Platform defined panic code */ -#define platform_panic(__x) { \ - mailbox_sw_reg_write(SRAM_REG_FW_STATUS, \ - (0xdead000 | (__x)) & 0x3fffffff); \ - ipc_write(IPC_DIPCIE, MAILBOX_EXCEPTION_OFFSET + 2 * 0x20000); \ - ipc_write(IPC_DIPCI, 0x80000000 | ((0xdead000 | (__x)) & 0x3fffffff)); \ +static inline void platform_panic(uint32_t p) +{ + mailbox_sw_reg_write(SRAM_REG_FW_STATUS, p & 0x3fffffff); + ipc_write(IPC_DIPCIE, MAILBOX_EXCEPTION_OFFSET + 2 * 0x20000); + ipc_write(IPC_DIPCI, 0x80000000 | (p & 0x3fffffff)); }
/* Platform defined trace code */ @@ -137,10 +138,6 @@ extern struct timer *platform_timer; * APIs declared here are defined for every platform and IPC mechanism. */
-int platform_boot_complete(uint32_t boot_message); - -int platform_init(struct sof *sof); - int platform_ssp_set_mn(uint32_t ssp_port, uint32_t source, uint32_t rate, uint32_t bclk_fs);
diff --git a/src/platform/baytrail/include/platform/platform.h b/src/platform/baytrail/include/platform/platform.h index 6a7ebc9..1defe27 100644 --- a/src/platform/baytrail/include/platform/platform.h +++ b/src/platform/baytrail/include/platform/platform.h @@ -33,6 +33,7 @@ #ifndef __PLATFORM_PLATFORM_H__ #define __PLATFORM_PLATFORM_H__
+#include <sof/platform.h> #include <platform/shim.h> #include <platform/interrupt.h> #include <uapi/ipc.h> @@ -102,20 +103,13 @@ struct sof; #define PLATFORM_IDLE_TIME 750000
/* Platform defined panic code */ -#define platform_panic(__x) { \ - shim_write(SHIM_IPCDL, (0xdead000 | (__x & 0xfff))); \ - shim_write(SHIM_IPCDH, (SHIM_IPCDH_BUSY | MAILBOX_EXCEPTION_OFFSET)); \ +static inline void platform_panic(uint32_t p) +{ + shim_write(SHIM_IPCDL, p); + shim_write(SHIM_IPCDH, (SHIM_IPCDH_BUSY | MAILBOX_EXCEPTION_OFFSET)); }
/* Platform defined trace code */ #define platform_trace_point(__x) \ shim_write(SHIM_IPCXL, (__x & 0x3fffffff)) -/* - * APIs declared here are defined for every platform and IPC mechanism. - */ - -int platform_boot_complete(uint32_t boot_message); - -int platform_init(struct sof *sof); - #endif diff --git a/src/platform/cannonlake/include/platform/platform.h b/src/platform/cannonlake/include/platform/platform.h index 88614ab..c7d4a82 100644 --- a/src/platform/cannonlake/include/platform/platform.h +++ b/src/platform/cannonlake/include/platform/platform.h @@ -34,6 +34,7 @@ #ifndef __PLATFORM_PLATFORM_H__ #define __PLATFORM_PLATFORM_H__
+#include <sof/platform.h> #include <platform/platcfg.h> #include <platform/shim.h> #include <platform/interrupt.h> @@ -117,12 +118,11 @@ struct sof; #define PLATFORM_IDLE_TIME 750000
/* Platform defined trace code */ -#define platform_panic(__x) { \ - mailbox_sw_reg_write(SRAM_REG_FW_STATUS, \ - (0xdead000 | (__x)) & 0x3fffffff); \ - ipc_write(IPC_DIPCIDD, MAILBOX_EXCEPTION_OFFSET + 2 * 0x20000); \ - ipc_write(IPC_DIPCIDR, 0x80000000 | \ - ((0xdead000 | (__x)) & 0x3fffffff)); \ +static inline void platform_panic(uint32_t p) +{ + mailbox_sw_reg_write(SRAM_REG_FW_STATUS, p & 0x3fffffff); + ipc_write(IPC_DIPCIDD, MAILBOX_EXCEPTION_OFFSET + 2 * 0x20000); + ipc_write(IPC_DIPCIDR, 0x80000000 | (p & 0x3fffffff)); }
/* Platform defined trace code */ @@ -135,10 +135,6 @@ extern struct timer *platform_timer; * APIs declared here are defined for every platform and IPC mechanism. */
-int platform_boot_complete(uint32_t boot_message); - -int platform_init(struct sof *sof); - int platform_ssp_set_mn(uint32_t ssp_port, uint32_t source, uint32_t rate, uint32_t bclk_fs);
diff --git a/src/platform/haswell/include/platform/platform.h b/src/platform/haswell/include/platform/platform.h index d30f329..b3d0609 100644 --- a/src/platform/haswell/include/platform/platform.h +++ b/src/platform/haswell/include/platform/platform.h @@ -32,6 +32,7 @@ #ifndef __PLATFORM_PLATFORM_H__ #define __PLATFORM_PLATFORM_H__
+#include <sof/platform.h> #include <platform/shim.h> #include <platform/interrupt.h> #include <uapi/ipc.h> @@ -101,20 +102,13 @@ struct sof; #define PLATFORM_IDLE_TIME 750000
/* Platform defined panic code */ -#define platform_panic(__x) { \ - shim_write(SHIM_IPCX, MAILBOX_EXCEPTION_OFFSET & 0x3fffffff); \ - shim_write(SHIM_IPCD, (SHIM_IPCD_BUSY | 0xdead000 | __x)); \ +static inline void platform_panic(uint32_t p) +{ + shim_write(SHIM_IPCX, MAILBOX_EXCEPTION_OFFSET & 0x3fffffff); + shim_write(SHIM_IPCD, (SHIM_IPCD_BUSY | p)) }
/* Platform defined trace code */ #define platform_trace_point(__x) \ shim_write(SHIM_IPCX, ((__x) & 0x3fffffff)) -/* - * APIs declared here are defined for every platform and IPC mechanism. - */ - -int platform_boot_complete(uint32_t boot_message); - -int platform_init(struct sof *sof); - #endif
From: Kamil Kulesza kamil.kulesza@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@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(-)
diff --git a/src/arch/xtensa/boot_entry.S b/src/arch/xtensa/boot_entry.S index 72d0e5e..5ebba16 100644 --- a/src/arch/xtensa/boot_entry.S +++ b/src/arch/xtensa/boot_entry.S @@ -81,6 +81,18 @@ wnd0_base_val: wnd0_size_val: .word HP_SRAM_WIN0_SIZE | 0x7
+wnd0_status_address: + .word HP_SRAM_WIN0_BASE + +wnd0_error_address: + .word HP_SRAM_WIN0_BASE | 0x4 + +fw_loaded_status_value: + .word 0x00000005 + +fw_no_errors_value: + .word 0x00000000 + boot_init: .align 4 #if defined(PLATFORM_DISABLE_L2CACHE_AT_BOOT) @@ -101,6 +113,16 @@ boot_init: l32r a3, sof_stack_base mov sp, a3
+ /* set status register to 0x00000005 in wnd0 */ + l32r a3, fw_loaded_status_value + l32r a5, wnd0_status_address + s32i a3, a5, 0 + + /* set error register to 0x00 in wnd0 */ + l32r a3, fw_no_errors_value + l32r a5, wnd0_error_address + s32i a3, a5, 0 + /* realloc memory window0 to continue reporting boot progress */ l32r a3, wnd0_size diff --git a/src/platform/apollolake/include/platform/memory.h b/src/platform/apollolake/include/platform/memory.h index 390b31b..6d4ea1b 100644 --- a/src/platform/apollolake/include/platform/memory.h +++ b/src/platform/apollolake/include/platform/memory.h @@ -348,7 +348,7 @@
/* boot loader in IMR */ #define IMR_BOOT_LDR_TEXT_ENTRY_BASE 0xB000A000 -#define IMR_BOOT_LDR_TEXT_ENTRY_SIZE 0x66 +#define IMR_BOOT_LDR_TEXT_ENTRY_SIZE 0x86 #define IMR_BOOT_LDR_LIT_BASE (IMR_BOOT_LDR_TEXT_ENTRY_BASE + \ IMR_BOOT_LDR_TEXT_ENTRY_SIZE) #define IMR_BOOT_LDR_LIT_SIZE 0x70 diff --git a/src/platform/cannonlake/include/platform/memory.h b/src/platform/cannonlake/include/platform/memory.h index 85e7996..f1a8aa5 100644 --- a/src/platform/cannonlake/include/platform/memory.h +++ b/src/platform/cannonlake/include/platform/memory.h @@ -353,7 +353,7 @@ #define IMR_BOOT_LDR_MANIFEST_SIZE 0x6000
#define IMR_BOOT_LDR_TEXT_ENTRY_BASE 0xB0038000 -#define IMR_BOOT_LDR_TEXT_ENTRY_SIZE 0x66 +#define IMR_BOOT_LDR_TEXT_ENTRY_SIZE 0x86 #define IMR_BOOT_LDR_LIT_BASE (IMR_BOOT_LDR_TEXT_ENTRY_BASE + IMR_BOOT_LDR_TEXT_ENTRY_SIZE) #define IMR_BOOT_LDR_LIT_SIZE 0x20 #define IMR_BOOT_LDR_TEXT_BASE (IMR_BOOT_LDR_LIT_BASE + IMR_BOOT_LDR_LIT_SIZE)
On Fri, 2018-06-08 at 19:42 +0100, Liam Girdwood wrote:
From: Kamil Kulesza kamil.kulesza@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@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(-)
Applied.
Thanks
Liam
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@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@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@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/sound-open-firmware
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.
Tomek
-----Original Message----- From: sound-open-firmware-bounces@alsa-project.org [mailto:sound-open-firmware-bounces@alsa-project.org] On Behalf Of Pan, Xiuli Sent: Monday, June 11, 2018 7:11 AM To: Liam Girdwood liam.r.girdwood@linux.intel.com; sound-open-firmware@alsa-project.org Cc: Kamil Kulesza kamil.kulesza@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@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@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@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/sound-open-firmware
_______________________________________________ Sound-open-firmware mailing list Sound-open-firmware@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.
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
Thanks Xiuli
Tomek
-----Original Message----- From: sound-open-firmware-bounces@alsa-project.org [mailto:sound-open-firmware-bounces@alsa-project.org] On Behalf Of Pan, Xiuli Sent: Monday, June 11, 2018 7:11 AM To: Liam Girdwood liam.r.girdwood@linux.intel.com; sound-open-firmware@alsa-project.org Cc: Kamil Kulesza kamil.kulesza@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@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@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@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/sound-open-firmware
Sound-open-firmware mailing list Sound-open-firmware@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@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/sound-open-firmware
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?
Thanks, ~Keyon
Thanks Xiuli
Tomek
-----Original Message----- From: sound-open-firmware-bounces@alsa-project.org [mailto:sound-open-firmware-bounces@alsa-project.org] On Behalf Of Pan, Xiuli Sent: Monday, June 11, 2018 7:11 AM To: Liam Girdwood liam.r.girdwood@linux.intel.com; sound-open-firmware@alsa-project.org Cc: Kamil Kulesza kamil.kulesza@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@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@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@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/sound-open-firmware
Sound-open-firmware mailing list Sound-open-firmware@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@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/sound-open-firmware
Sound-open-firmware mailing list Sound-open-firmware@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/sound-open-firmware
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?
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@alsa-project.org [mailto:sound-open-firmware-bounces@alsa-project.org] On Behalf Of Pan, Xiuli Sent: Monday, June 11, 2018 7:11 AM To: Liam Girdwood liam.r.girdwood@linux.intel.com; sound-open-firmware@alsa-project.org Cc: Kamil Kulesza kamil.kulesza@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@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@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@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/sound-open-firmware
Sound-open-firmware mailing list Sound-open-firmware@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@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/sound-open-firmware
Sound-open-firmware mailing list Sound-open-firmware@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/sound-open-firmware
Sound-open-firmware mailing list Sound-open-firmware@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/sound-open-firmware
-----Original Message----- From: sound-open-firmware-bounces@alsa-project.org [mailto:sound-open- firmware-bounces@alsa-project.org] On Behalf Of Pan, Xiuli Sent: Monday, June 11, 2018 5:52 PM To: Keyon Jie yang.jie@linux.intel.com; sound-open-firmware@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@alsa-project.org [mailto:sound-open-firmware-bounces@alsa-project.org] On Behalf Of Pan, Xiuli Sent: Monday, June 11, 2018 7:11 AM To: Liam Girdwood liam.r.girdwood@linux.intel.com; sound-open-firmware@alsa-project.org Cc: Kamil Kulesza kamil.kulesza@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@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@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@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/sound-open-firmwar e
Sound-open-firmware mailing list Sound-open-firmware@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@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/sound-open-firmware
Sound-open-firmware mailing list Sound-open-firmware@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/sound-open-firmware
Sound-open-firmware mailing list Sound-open-firmware@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/sound-open-firmware
Sound-open-firmware mailing list Sound-open-firmware@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/sound-open-firmware
On 6/11/2018 22:17, sound-open-firmware-bounces@alsa-project.org wrote:
-----Original Message----- From: sound-open-firmware-bounces@alsa-project.org [mailto:sound-open- firmware-bounces@alsa-project.org] On Behalf Of Pan, Xiuli Sent: Monday, June 11, 2018 5:52 PM To: Keyon Jie yang.jie@linux.intel.com; sound-open-firmware@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?
DMA trace will not work after FW ready. It will need IPC mailbox to send the offset.
Thanks Xiuli
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@alsa-project.org [mailto:sound-open-firmware-bounces@alsa-project.org] On Behalf Of Pan, Xiuli Sent: Monday, June 11, 2018 7:11 AM To: Liam Girdwood liam.r.girdwood@linux.intel.com; sound-open-firmware@alsa-project.org Cc: Kamil Kulesza kamil.kulesza@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@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@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@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/sound-open-firmwar e
Sound-open-firmware mailing list Sound-open-firmware@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@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/sound-open-firmware
Sound-open-firmware mailing list Sound-open-firmware@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/sound-open-firmware
Sound-open-firmware mailing list Sound-open-firmware@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/sound-open-firmware
Sound-open-firmware mailing list Sound-open-firmware@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/sound-open-firmware
On Mon, 2018-06-11 at 13:10 +0800, Pan, Xiuli wrote:
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@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@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.
Xiuli/Liam/Tomasz,
There is a regression due to the set of the bootloader patches on my up squared board. The audio is distorted now.
I reverted these patches and I could hear clean audio.
Thanks, Ranjani
Thanks Xiuli
Applied.
Thanks
Liam _______________________________________________ Sound-open-firmware mailing list Sound-open-firmware@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/sound-open-firmwar e
Sound-open-firmware mailing list Sound-open-firmware@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/sound-open-firmware
On 2018年06月12日 11:51, Ranjani Sridharan wrote:
On Mon, 2018-06-11 at 13:10 +0800, Pan, Xiuli wrote:
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@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@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.
Xiuli/Liam/Tomasz,
There is a regression due to the set of the bootloader patches on my up squared board. The audio is distorted now.
I reverted these patches and I could hear clean audio.
+ Keqiao who may reported similar issue on UP^2. Hi Keqiao, can you check what Ranjani founded?
Thanks, ~Keyon
Thanks, Ranjani
Thanks Xiuli
Applied.
Thanks
Liam _______________________________________________ Sound-open-firmware mailing list Sound-open-firmware@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/sound-open-firmwar e
Sound-open-firmware mailing list Sound-open-firmware@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/sound-open-firmware
Sound-open-firmware mailing list Sound-open-firmware@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/sound-open-firmware
On 12.06.2018 06:28, Keyon Jie wrote:
On 2018年06月12日 11:51, Ranjani Sridharan wrote:
On Mon, 2018-06-11 at 13:10 +0800, Pan, Xiuli wrote:
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@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@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.
Xiuli/Liam/Tomasz,
There is a regression due to the set of the bootloader patches on my up squared board. The audio is distorted now.
I reverted these patches and I could hear clean audio.
- Keqiao who may reported similar issue on UP^2.
Hi Keqiao, can you check what Ranjani founded?
Thanks, ~Keyon
Glitches are probably due to the problem with Host DMA not exiting L1 state on time. Bootloader patch enabled L1 cache on APL, so that's why you are seeing the problem now. It will be fixed after my pm_runtime patch will go through.
Thanks, Ranjani
Thanks Xiuli
Applied.
Thanks
Liam _______________________________________________ Sound-open-firmware mailing list Sound-open-firmware@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/sound-open-firmwar e
Sound-open-firmware mailing list Sound-open-firmware@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/sound-open-firmware
Sound-open-firmware mailing list Sound-open-firmware@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/sound-open-firmware
Sound-open-firmware mailing list Sound-open-firmware@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/sound-open-firmware
On Tue, 2018-06-12 at 09:44 +0200, Lauda, Tomasz wrote:
Xiuli/Liam/Tomasz,
There is a regression due to the set of the bootloader patches on my up squared board. The audio is distorted now.
I reverted these patches and I could hear clean audio.
- Keqiao who may reported similar issue on UP^2.
Hi Keqiao, can you check what Ranjani founded?
Thanks, ~Keyon
Glitches are probably due to the problem with Host DMA not exiting L1 state on time. Bootloader patch enabled L1 cache on APL, so that's why you are seeing the problem now. It will be fixed after my pm_runtime patch will go through.
This may probably also benefit with the new HDA DMA GW optimal programming flow that Marcin has suggested too.
Liam --------------------------------------------------------------------- Intel Corporation (UK) Limited Registered No. 1134945 (England) Registered Office: Pipers Way, Swindon SN3 1RJ VAT No: 860 2173 47
This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
On 6/12/2018 15:50, Liam Girdwood wrote:
On Tue, 2018-06-12 at 09:44 +0200, Lauda, Tomasz wrote:
Xiuli/Liam/Tomasz,
There is a regression due to the set of the bootloader patches on my up squared board. The audio is distorted now.
I reverted these patches and I could hear clean audio.
- Keqiao who may reported similar issue on UP^2.
Hi Keqiao, can you check what Ranjani founded?
Thanks, ~Keyon
Glitches are probably due to the problem with Host DMA not exiting L1 state on time. Bootloader patch enabled L1 cache on APL, so that's why you are seeing the problem now. It will be fixed after my pm_runtime patch will go through.
This may probably also benefit with the new HDA DMA GW optimal programming flow that Marcin has suggested too.
So if anyone has idea why there are duplicate data in the Memory Window? And a memset could not set all data in MW3. If these is also related with cache?
Thanks Xiuli
Liam
Intel Corporation (UK) Limited Registered No. 1134945 (England) Registered Office: Pipers Way, Swindon SN3 1RJ VAT No: 860 2173 47
This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. _______________________________________________ Sound-open-firmware mailing list Sound-open-firmware@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/sound-open-firmware
On Fri, 2018-06-08 at 19:42 +0100, Liam Girdwood wrote:
From: Marcin Maka marcin.maka@linux.intel.com
Common platform API separated to avoid duplicated declarations and group public functions to be implemented by every platform.
Signed-off-by: Marcin Maka marcin.maka@linux.intel.com
src/include/sof/panic.h | 4 +- src/include/sof/platform.h | 60 +++++++++++++++++++ .../apollolake/include/platform/platform.h | 15 ++--- .../baytrail/include/platform/platform.h | 16 ++--- .../cannonlake/include/platform/platform.h | 16 ++--- .../haswell/include/platform/platform.h | 16 ++--- 6 files changed, 83 insertions(+), 44 deletions(-) create mode 100644 src/include/sof/platform.h
Applied.
Thanks
Liam
participants (8)
-
Jie, Yang -
Keyon Jie -
Lauda, Tomasz -
Lauda, Tomasz -
Liam Girdwood -
Liam Girdwood -
Pan, Xiuli -
Ranjani Sridharan