On 1/23/19 12:54 AM, Lukasz Majewski wrote:
Hi Tom,
On Tue, Jan 22, 2019 at 11:43:33PM +0100, Lukasz Majewski wrote:
On Thu, 17 Jan 2019 13:43:04 -0600 "Andrew F. Davis" afd@ti.com wrote:
CLI support with the HUSH parser is not currently SPL safe due to it's use of realloc. That function is not defined for SPLs that use SYS_MALLOC_SIMPLE. CLI support can be built in to SPL and some functions do work, but use of some like run_command() will cause build to fail. When no SPL code calls this function build works as the compiler removes this unreachable code so the unresolved symbols are ignored.
If DFU support is enabled in SPL then MMU DFU support may get brought in also, this code does make a call to run_command() causing build to fail if the HUSH parser is not built-in. To break this odd and unneeded dependency chain we use CONFIG_IS_ENABLED where appropriate to prevent calls into HUSH code from SPL. This also removes our need to pull in the rather unrelated source file when SPL_DFU is defined.
If I remember correctly the HUSH was _required_ by TI to be able to use DFU in SPL (and that was a rationale to add it to SPL - which IMHO was wrong from the outset).
What has changed that it is not needed anymore?
The cli_simple code can now handle all the common DFU commands I was able to throw at it, so the full HUSH is not needed anymore.
To be fair, it was probably me-at-TI rather than TI that said it was required. At the time it was enough of a PITA to try and handle all of the cases that the dfu cli command handled via API calls instead that at least in my opinion, it wasn't worth re-whacking everything else. Times have changed it seems :)
I don't mind :-).
Less code in SPL - the better.
+1
Andrew
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@denx.de