On Wed, Jun 10, 2026 at 05:59:05PM +0900, Daniel Palmer wrote: > Hi Quentin, > > On Wed, 10 Jun 2026 at 17:47, Quentin Schulz <[email protected]> wrote: > > I'm fine fixing what needs to be fixed now and improvements later on. > > Ok, I'll wait for if/when Tom replies and maybe send a v3 just fixes > the main u-boot part.
Yes, lets just do the fixes for now, and Kconfig / Makefile logic cleanups later. > > Note that we generally do not like complete rewrites in one patch but > > rather small incremental changes (which may end up in the same result, > > but is "more reviewable"). We don't have a maintainer for that feature, > > though Tom is the "catch-all" maintainer, so maybe you can convince him > > a full rewrite is ok. In any case, I'm sure we would really appreciate > > tests (I don't think we have any from the cursory check I just made) so > > make sure to include some (especially for the issues you encountered so > > we don't regress!). > > I haven't touched it for a long time. But from what I remember fixing > the issues in it was basically rewriting it because of the code style > etc being so different from the rest of u-boot. > Maybe I can use AI for good and have it generate a series of patches > from my version. I'm assuming sensible non-spam AI assisted changes > are ok :) Since Quentin already sent my answer about AI (thanks!), what I'll add here is that yes, xyzModem.c is very old, but, there's known (to me) issues with it either. If someone really wants to replace that with a modern version (that's equal or better in terms of binary size (CMD_LOADB is enabled on virtually every platform) maybe Zephyr has something we can borrow that's appropriately licensed? When touching code that's enabled in a large percent of the platforms I become very concerned with the tradeoffs between binary size and whatever the new functionality is. Thanks! -- Tom
signature.asc
Description: PGP signature
