[U-Boot-Users] [PATCH 6/17] Reorganize and fix problems (returns) in the bootm command.
Jerry Van Baren
gerald.vanbaren at smiths-aerospace.com
Thu Jul 5 16:30:37 CEST 2007
Grant Likely wrote:
> On 7/5/07, Jerry Van Baren <gvb.uboot at gmail.com> wrote:
>> Grant Likely wrote:
>>> On 7/4/07, Jerry Van Baren <gvb.uboot at 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 at 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
More information about the U-Boot
mailing list