Difference between revisions of "Multi-core"
From Wiki at Neela Nurseries
m (Build invocations and BOARD_ROOT setting) |
m (→^ Build invocations and BOARD_ROOT setting) |
||
| Line 37: | Line 37: | ||
== [[#top|^]] Build invocations and BOARD_ROOT setting == | == [[#top|^]] Build invocations and BOARD_ROOT setting == | ||
| − | 1361 west build -b | + | 1361 west build -b lpcxpresso55s69_cpu0 -t menuconfig -- -DBOARD_ROOT=../.. |
<!-- comentario --> | <!-- comentario --> | ||
| − | |||
| − | |||
== [[#top|^]] General MCU bring-up == | == [[#top|^]] General MCU bring-up == | ||
Revision as of 22:56, 19 December 2022
In Zephyr 3.2.0 see `zephyr/include/zephyr/drivers/ipm.h` for some starting points to understand inter-processor messaging.
One of two or three Zephyr 3.2.0 sample apps which touch on multi-core firmware design:
- ./subsys/ipc/openamp/boards/lpcxpresso55s69_cpu0.overlay
Contents
^ Zephyr sys init run levels
Likely for another local article, excerpt from `zephyr/include/zephyr/init.h`:
18 /* 19 * System initialization levels. The PRE_KERNEL_1 and PRE_KERNEL_2 levels are 20 * executed in the kernel's initialization context, which uses the interrupt 21 * stack. The remaining levels are executed in the kernel's main task. 22 */ 23 24 #define _SYS_INIT_LEVEL_PRE_KERNEL_1 0 25 #define _SYS_INIT_LEVEL_PRE_KERNEL_2 1 26 #define _SYS_INIT_LEVEL_POST_KERNEL 2 27 #define _SYS_INIT_LEVEL_APPLICATION 3 28 29 #ifdef CONFIG_SMP 30 #define _SYS_INIT_LEVEL_SMP 4 31 #endif
^ Build invocations and BOARD_ROOT setting
1361 west build -b lpcxpresso55s69_cpu0 -t menuconfig -- -DBOARD_ROOT=../..
^ General MCU bring-up
NXP LPC55S69 system clock settings HAL source file:
$ vi ./hal/nxp/mcux/mcux-sdk/devices/LPC55S69/drivers/fsl_clock.h
^ NXP mailbox HAL files
modules/hal/nxp/mcux/mcux-sdk/drivers/mailbox/fsl_mailbox.h
Size of data block which mailbox can send:
$ grep -nr MCUX_IPM_DATA_REGS ./*
./nexus-gateway-firmware/samples/ipm_mcux/build/zephyr/zephyr.lst:8385: return MCUX_IPM_DATA_REGS*sizeof(uint32_t);
./nexus-gateway-firmware/samples/ipm_mcux/build/zephyr/zephyr.lst:8433: if (size > MCUX_IPM_DATA_REGS * sizeof(uint32_t)) {
./nexus-gateway-firmware/samples/ipm_mcux/build/ipm_mcux_remote-prefix/src/ipm_mcux_remote-build/zephyr/zephyr.lst:6266: return MCUX_IPM_DATA_REGS*sizeof(uint32_t);
./nexus-gateway-firmware/samples/ipm_mcux/build/ipm_mcux_remote-prefix/src/ipm_mcux_remote-build/zephyr/zephyr.lst:6314: if (size > MCUX_IPM_DATA_REGS * sizeof(uint32_t)) {
./tags:6361980:MCUX_IPM_DATA_REGS zephyr/drivers/ipm/ipm_mcux.c 16;" d file:
./zephyr/drivers/ipm/ipm_mcux.c:16:#define MCUX_IPM_DATA_REGS 1
./zephyr/drivers/ipm/ipm_mcux.c:82: uint32_t data32[MCUX_IPM_DATA_REGS]; /* Until we change API
./zephyr/drivers/ipm/ipm_mcux.c:94: if (size > MCUX_IPM_DATA_REGS * sizeof(uint32_t)) {
./zephyr/drivers/ipm/ipm_mcux.c:117: return MCUX_IPM_DATA_REGS*sizeof(uint32_t);
Binary file ./zephyr/drivers/ipm/.ipm_mcux.c.swp matches
174 /**
175 * @brief Return the maximum number of bytes possible in an outbound message.
176 *
177 * IPM implementations vary on the amount of data that can be sent in a
178 * single message since the data payload is typically stored in registers.
179 *
180 * @param ipmdev Driver instance pointer.
181 *
182 * @return Maximum possible size of a message in bytes.
183 */
184 __syscall int ipm_max_data_size_get(const struct device *ipmdev);
185
186 static inline int z_impl_ipm_max_data_size_get(const struct device *ipmdev)
187 {
188 const struct ipm_driver_api *api =
189 (const struct ipm_driver_api *)ipmdev->api;
190
191 return api->max_data_size_get(ipmdev);
192 }
Following in-tree Zephyr driver shows all the MCUX mailbox API routine prototypes, with explanatory comments, and shows Zephyr's `z_impl_` convention of naming device API function wrappers with names that begin with this pattern:
zephyr/include/zephyr/drivers$ vi ipm.h
Some other processors have greater data sizes which can be passed via their mailboxes, as indicated in this file:
zephyr/drivers/ipm/Kconfig.imx
