[PATCH] xyzModem: Correct xmodem blk verification conditions

jihongbin jhb_ee at 163.com
Tue Feb 6 14:05:33 CET 2024


It may be that there are relatively few people using this function, or 
the length of the transmitted data is less than 128byte * 255 byte, so 
the triggering conditions for the above problems are not encountered;

I actually discovered this problem during testing. Continuous 
transmission always fails at block 255.

The following is the protocol's definition of blk cblk, cblk = 255 - blk
The original content of the agreement 
(https://www.menie.org/georges/embedded/xmodem_specification.html) is as 
follows:
-------- 3. MESSAGE BLOCK LEVEL PROTOCOL
Each block of the transfer looks like:
<SOH><blk #><255-blk #><--128 data bytes--><cksum>
in which:
<SOH> = 01 hex
<blk #> = binary number, starts at 01 increments by 1, and
wraps 0FFH to 00H (not to 01)
<255-blk #> = blk # after going thru 8080 "CMA" instr, i.e.
each bit complemented in the 8-bit block number.
Formally, this is the "ones complement".

<cksum> = the sum of the data bytes only. Toss any carry.



在 2024/2/5 22:25, Dan Carpenter 写道:
> On Mon, Feb 05, 2024 at 02:58:50PM +0800, Hongbin Ji wrote:
>> When the blk sequence number is 255 and cblk is 0, the original XOR condition
>> produces a result of 0,and the judgment condition will be unsuccessful.
>>
> This code is 18 years old so it's surprising that it's causing an issue
> now.  This was added in commit f2841d377060 ("Add support for ymodem
> protocol (loady command). Patch by Stefano Babic, 29 Mar 2006").
>
> Not just 255 and zero but any time "blk == 255 - cblk" then your new
> condition will be true where the original condition was false.  Is that
> really intentional?  Is this from reviewing documentation or something?
> What documents?  Or is it from testing?
>
> regards,
> dan carpenter


More information about the U-Boot mailing list