On Fri, Sep 21, 2018 at 1:43 PM Wolfgang Denk <[email protected]> wrote: > > Dear Alex, > > In message <[email protected]> you wrote: > > When the image which bootm is given can't be booted, call panic with > > the error message rather than printf/hang so that we can recover from > > broken images via a bootcount mechanism. If hang on failure is still > > required then CONFIG_PANIC_HANG can still be enabled. > > I wonder if the failing of the FDT creation is a reason to panic / > reboot at all? The point of no return is architecture dependent - > for example, on Power architecture it is usuallywhen the kernel > image gests decompressed/written to RAM, as then the exception > vectors get overwritten, so no return to U-Boot is possible. > > But the FDT is always (I think ?) just written to an area of RAM > that is not critical for the execution of U-Boot itself - so when > this fails, why can we not simply return to U-Boot with an eroor > indication? > > I feel we should use panic/hang only as a last resort, when no other > recovery is possible? >
Thinking it through, that sounds reasonable to me... the reason I ended up looking at this code was because I deployed a broken FIT image, then got stuck here. But if bootm had returned with a failure I could have done useful recovery actions without needing a reboot. -- Alex Kiernan _______________________________________________ U-Boot mailing list [email protected] https://lists.denx.de/listinfo/u-boot
