[U-Boot-Users] [PATCH 6/17] Reorganize and fix problems (returns) in the bootm command.

[Jerry Van Baren <gerald.vanbaren@smiths-aerospace.com>]

Grant Likely wrote:
> On 7/5/07, Jerry Van Baren <gvb.uboot@gmail.com> wrote:
>> Grant Likely wrote:
>>> On 7/4/07, Jerry Van Baren <gvb.uboot@gmail.com> wrote:
>>>> Do *NOT* return after the "point of no return" has been passed.
>>>>   If something goes wrong, the board must be reset after that point.
>>>> Move the "Transferring control to Linux" debug message back to where it
>>>>   belongs: just before transferring control to linux.
>>> Why is it necessary to reset the board at this point?  The failure
>>> paths here seem to be things like invalid checksums and the like.  Why
>>> are these tests after a point of no return?
>>>
>>> I would think that if any of these failures are hit, you would *not*
>>> want to reset the board so you can figure out what was going on.
>>>
>>> Cheers,
>>> g.
>> We've smashed our underpinnings by uncompressing linux over our
>> interrupt vectors before the checksum catches the problem.  There is no
>> way back other than a reset.  The error I fixed (in a couple of places)
>> was returns.  FWIIW, my experience with the erroneous returns is that it
>> sort of works, but not right and then funky stuff happens. :-/
>>
>> I presume the comment was a general one.  If you have any specific reset
>> vs. return questions, hollar and I'll justify them or eat crow.
> 
> Ah, okay that makes sense.  So the obvious next question is: can any
> of those tests be performed before uncompressing Linux?  If so, then
> they probably should be moved.  If not...
> 
> Acked-by: Grant Likely <grant.likely@secretlab.ca>

Sorry, no.  The CRC is over the uncompressed data, and for good reason - 
it will detect if Something Bad[tm] happened during the decompression. 
The good news is, the reset-to-recover path /should/ never be taken.

gvb