-
Notifications
You must be signed in to change notification settings - Fork 6.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Convert subsys/mgmt to new kwork API #34101
Comments
@Navin-Sankar is more appropriate person to handle subsys/mgmt/hawkbit/hawkbit.c |
I can handle updatehub. |
Chip shortages don't effect software ;). |
I have just notified you so the delay is like 6 hours so far ;). |
@de-nordic yes, on this, but I think there are others with more than 2 weeks. |
It has been tough weeks these days and I can only help on my free time. |
I don't understand what is happening. frdm-k64f, and nucleo_f767zi don't boot zephyr image. frdm-k64f I know that @henrikbrixandersen will fix code at Zephyr side soon, so I have a workaround at MCUboot for now. However, frdm-k64f and nrf52840dk_nrf52840 doesn't confirm image. My last good Zephyr image is from early Dec/20. Since there, everything stop to work and now even confirm image don't work. The steps are so simple to test and see that board don't work:
The below log is from nRF.
UpdateHub start code freeze by 2.3 for LTS. We only made changes on the sample to allow network management for (ETH, WIFI, IEEE-802.15.4, BLE and OT). Right now, no one can use that and we lost, at least, 1 year of work if Zephyr and MCUboot won't work. I rely hope you guys can stable MCUboot and Zephyr soon. Let me know when you have a good version so I can test. CC: @otavio |
Replace all existing deprecated API with the recommended alternative. Fixes: zephyrproject-rtos#34101 Signed-off-by: Peter Bigot <[email protected]> Signed-off-by: Gerson Fernando Budke <[email protected]>
What is more concerning is that this kind of regression has become a habit inside the Zephyr project. What actions are on course to avoid this from happening in the future? How can developers trust Zephyr for critical devices and upgrade to new Zephyr releases with such bad regression tracking? |
@nandojve I am also experiencing the same error. hawkbit image doesn't boot with frdm_k64f board.
mcuboot doesn't handover the control to hawkbit image. |
I will look into the problem on nrf52840dk. |
@nandojve Can you give me sha of the Zephyr commit you are using? As I understand, the image confirmation is done so that there would be no attempt to update device from unconfirmed image, right? I have problem with reproducing that on nrf52840dk; I have build the updathub sample with ot overlays and programmed the image to the board.
Can you send me some more context? |
Hello, it was #5520 from yesterday. Probably we are at same point by v2.5.0- What are below differences? If we are supposed to use same build/flash commands why we got different values? nandojve
de-nordic
|
in Zephyr dir, clean master (383700b), west update and so on, then
I do menuconfig to set the mcuboot key and increase log levels, then I got:
But this is just from last run. The log I have gave you previously has been received after I have already flashed several updatehub images and even smp_svr (with the same mcuboot) to check if the |
@nandojve any updates on this? |
Just for record. Now there is #34530. The big question is: when MCUboot/Zephyr API/infrastructure will be stable? What happened with 3 versions API before deprecate? There will be multiple ways for LTS? This difficult what is best time to explore and fix problems. BTW I didn't look yet #34530 but my felling is that may brake device compatibility. User will be stuck with their current version and can't upgrade to a newer version, only fixups. Is that true? Note: I understand project wants what is best for LTS but I think we can not do everything. If we do everything, there won't be a 3.0. My feeling is this "madness" should stop. This create a sense of insecurity and this project never will have chance to be reliable. |
The change is supposed to maintain the compatibility with current API, generally you should be able to get flash area by ID, determined from DTS by label ( |
Replace all existing deprecated API with the recommended alternative. Fixes: #34101 Signed-off-by: Peter Bigot <[email protected]> Signed-off-by: Gerson Fernando Budke <[email protected]>
Convert subsys/mgmt/hawkbit/hawkbit.c & subsys/mgmt/updatehub/updatehub.c to use new kwork API.
See the following issue for details:
#33104
The text was updated successfully, but these errors were encountered: