tmedicci commented on PR #16533: URL: https://github.com/apache/nuttx/pull/16533#issuecomment-2971254062
> > > Also you can include a test to verify if ESP_HAL_3RDPARTY_VERSION_FOR_MCUBOOT != ESP_HAL_3RDPARTY_VERSION, if so show a warning explaining current HAL broke MCUBOOT and a proper fix needs to be found. > > > > > > Hi Alan, > > I can't do this as the whole point of this PR is to have a different version for Espressif's MCUBoot port. That's why it says "decoupling" on the commit. `ESP_HAL_3RDPARTY_VERSION_FOR_MCUBOOT` and `ESP_HAL_3RDPARTY_VERSION` are only the same for now, very soon this will not be possible. > > @fdcavalcanti Yes, I understood that, but MCUBOOT is expected to work with the most up-to-date HAL, isn't it? If it's failing, it means something needs to be fixed. Otherwise the user could continue using an outdated HAL for a long time (years). I think the idea of ​​migrating to ESP's HAL was exactly to simplify the development "burden" and keep up-to-date with the new Espressif HAL! :-) > > If MCUBOOT can work with the most up-to-date HAL, why to use a different (old) HAL? MCUboot _Espressif_ port is meant to be OS-agnostic, Alan, so it should not depend on a specific HAL for any OS. On the other hand, we can't support multiple versions of the HAL on MCUboot (imagine having the same MCUboot version which is built using different HAL versions: a maintenance nightmare!). That being said, MCUboot is a firmware that is built once and flashed once in the board: it should rely on a _very_ stable HAL version which is not meant to be updated unless strictly necessary. Decoupling OS's HAL from MCUboot makes it possible to keep updating the OS without messing with MCUboot. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: commits-unsubscr...@nuttx.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
