Fixes for zephyr 4.0 #16770
Fixes for zephyr 4.0 #16770
Conversation
8e9af9f to
0492841
Compare
The (deprecated) kconfig option NET_SOCKETS_POSIX_NAMES was removed in commit abad505bdeed6102061767f45acd63323973f564 so remove it from our configuration. As the option has been deprecated longer, this also works for v3.7 and v4.0 the other still supported versions. Signed-off-by: Detlev Zundel <[email protected]>
0492841 to
95f30d7
Compare
The function "thread_analyzer_print" requires an unsigned int paramter since commit 1b6e0f64796dfd6f86a8679ea6d24e1fca1e63a8 even though it is ignored when THREAD_ANALYZER_AUTO_SEPARATE_CORES=n which is the default on single core machines. Signed-off-by: Detlev Zundel <[email protected]>
0162000 to
93d63b5
Compare
|
Interesting. One day nothing happens and suddenly a "This branch must not contain merge commits" error/warning shows up. I have no idea, where this comes from, this branch was freshly rebased onto master shortly before opening the PR and certainly contains no merge commit from myself. Should I do something about this? |
It looks like that error is gone now? GitHub has recently updated the "merge experience" so maybe some teething issues which have been resolved. Anyway, things look good now. |
|
Hi Damien, thanks fir looking into this!
I still do see a red "Merging is blocked" warning/error, but I have no idea if this prevents anything.
That sounds good! I am looking forward to feedback on the series. Best wishes |
ports/zephyr/main.c
Outdated
| bdev = MP_OBJ_TYPE_GET_SLOT(&zephyr_disk_access_type, make_new)(&zephyr_disk_access_type, ARRAY_SIZE(args), 0, args); | ||
| mount_point_str = "/sd"; | ||
| #elif defined(CONFIG_FLASH_MAP) && FIXED_PARTITION_EXISTS(storage_partition) | ||
| mp_obj_t args[] = { MP_OBJ_NEW_SMALL_INT(FIXED_PARTITION_ID(storage_partition)), MP_OBJ_NEW_SMALL_INT(4096) }; | ||
| #define DT_DRV_COMPAT zephyr_flash_disk | ||
| mp_obj_t args[] = { MP_OBJ_NEW_SMALL_INT(FIXED_PARTITION_ID(storage_partition)), MP_OBJ_NEW_SMALL_INT(DT_INST_PROP(0, cache_size)) }; |
There was a problem hiding this comment.
This change (to retrieve cache-size from the device tree) now requires all boards that use this bit of code to have this defined. And that seems to be something you have to now manually do.
Eg, with this PR the existing nucleo_h743zi board fails to build (using Zephyr v3.7.0):
zephyr/include/zephyr/devicetree.h:336:40: error: 'DT_N_INST_0_zephyr_flash_disk_P_cache_size' undeclared (first use in this function)
There was a problem hiding this comment.
Hi Damien, thanks for looking into the patches! And yes, you are right. I do not have an overview of how many boards are affected, but I see that this is a problem. Would it be ok, to check if such a property exists and if not use the hard coded 4 Kib instead? I'll try to rework that patch in this way.
There was a problem hiding this comment.
Would it be ok, to check if such a property exists and if not use the hard coded 4 Kib instead?
Yes, if that's possible, that would be good.
There was a problem hiding this comment.
I just force-pushed an update with this modification. In order to let people know that the device tree should be updated, I inserted a corresponding #warning. I hope this is ok?
Also, I rewrote the device tree access not to use the #DT_DRV_COMPAT macro that I used previously. I think things should be self-contained, even if that takes longer to express in code.
I am having a lot of problems getting the code formatting right 🤦
Commit 07a8e3253a2d8a2076c9c83c4ed4158fa3fbb2a2 removes CONFIG_MMC_VOLUME_NAME from the Kconfig space. Instead we need to use the device tree to find the "disk-name" property of "zephyr,mmc-disk" devices. Signed-off-by: Detlev Zundel <[email protected]>
With this overlay, we can read the 'cache-size' parameter for the erase block size instead of hard coding it. Signed-off-by: Detlev Zundel <[email protected]>
451822f to
48479fe
Compare
The block_size parameter needs to be read from the device tree property 'cache-size' rather than hard-coding it to 4096. For backwards compatibility, we do this only if such a property exists but output a warning otherwise, so the device trees missing this property can be updated. Signed-off-by: Detlev Zundel <[email protected]>
The configuration uses the partition 'storage_partition' in the external QSPI flash for file system storage. Signed-off-by: Detlev Zundel <[email protected]>
48479fe to
da25ac2
Compare
|
See #16207 |
|
Thanks, Maureen, that explains a few things 😄. Let me comment on possible ways to join forces here. So if I see things correctly, then #16207 was not merged because that represents an either v3.7 or v4.0 path for MicroPython. This PR supports both versions (and main as of recent) and so the question is probably what stance MicroPython will take with regard to the required Zephyr version. For this patch set, my reasoning was that the currently supported versions of Zephyr are v3.7 (LTS) and v4.0, so MicroPython should work with both - if possible. For the current patch set, this worked, but I am not sure if this will always be possible. #16207 is better with respect to thread_analyzer. I am not so sure if MicroPython will run on multiple cores in the near future, but on the other hand doing it the right way is not a lot more work, so I would prefer #16207. Lastly this PR includes the addition for reading the erase block size for flash_map which probably should also go in (it is required when using the internal flash on mcxn947 with an erase block size of 8192 instead of the external QSPI flash). |
|
Nice work, I'm happy to help with testing as I have recently started doing some work on getting power management working in zephyr for nrf see here. I have a nrf5340DK and nrf9151DK for testing. |
|
So without hearing anything to the contrary, I compiled such a "best of" PR which supports all upstream Zephyr versions and rebased it on current master: #16879 This closely misses the Zephyr v4.1 release, but the patch set also works on today's main branch of Zephyr. I compile tested for the two NXP boards and hope that other boards will also work, but I am optimistic that we can fix upcoming problems quickly. I think it is a worthwhile goal to be more permissive on the upstream versions and amended the documentation in this sense. Let me know if things work for you, and I am looking forward to feedback whether the direction looks good to everyone involved! |
Summary
Some fixes for Zephyr port for v4.0 and beyond. Without some of those changes, neither the current version v4.0 nor the current development version even compile. The commits clearly explain the reason for the change with links to the original commits. The patches were tested with an SD card and a QSPI flash system.
Testing
I tested the patches on all currently supported Zephyr versions, i.e. v3.7, v4.0 and top-of-tree v4.0.0-5122-gcb772b0f60c on two boards:
On the mimxrt1060 I tested the SD support by injecting -DCONFIG_DISK_ACCESS=y into the build. I did not change the default configuration as this hangs when no SD card is discovered and so people should only enable it if they want to use such a system.
For the frdm_mcxn947 I added a device tree overlay and a config fragment to enable the functionality out of the box as the flash is always present, and I did not see any slowdown with the functionality.
I blogged the whole journey on my blog:
https://blog.lazy-evaluation.net/posts/embedded/micropython-zephyr-imxrt1060.html
https://blog.lazy-evaluation.net/posts/embedded/micropython-zephyr-mcxn947.html