[ECOS] redboot

[ECOS] redboot

[Jörg Rapka]

Dear ecos developer

I'm very interested in the redboot of ecos.
I have downloaded the latest version from CVS.
In the sources I found the information, that
not only download by TFTP but also xyzmodem
will be supported (the documentation only
references TFTP). I compiled the sources
and tried download by xyzmodem, but it did
not work so well.
What is the status of this implementation?
What was your terminal application and protocol
used during development tests?

Best regards, Joerg

RE: [ECOS] redboot

[Gary Thomas]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 738 bytes --]

On 07-Nov-2000 Jörg Rapka wrote:
> Dear ecos developer
> 
> I'm very interested in the redboot of ecos.
> I have downloaded the latest version from CVS.
> In the sources I found the information, that
> not only download by TFTP but also xyzmodem
> will be supported (the documentation only
> references TFTP). I compiled the sources
> and tried download by xyzmodem, but it did
> not work so well.
> What is the status of this implementation?
> What was your terminal application and protocol
> used during development tests?

Currently only Ymodem (or Xmodem with CRC) is implemented.

What platform did you try this on?
What problems did you encounter?

It's pretty hard to help much if all you give us is "it did
not work so well."

AW: [ECOS] redboot

[Jorg Rapka]

Dear Gary

Sorry for this: "it did not work so well."

Here are a lot of information!

My platform is a Motorola 68331.

What problems did encounter:
- I'm connected by a serial line with a terminal (COM7.1 from tlgmicro).
  I start the download process with command "load". Now the character
  'C' will be send by redboot to start the transmission.
- I start with XMODEM CRC (use 128 byte per data block). This protocol
  did not send the file name as first data block. So I get into
  trouble in function "xyzModem_stream_open".
  For the YMODEM protocol you ignore this file name data block:
   // Note: yModem file name data blocks quietly discarded
   xyz.next_blk = 1;
   xyz.len = 0;
  I replaced the above code by this one:
   if (mode == xyzModem_xmodem) {
       xyz.next_blk = 2;
   } else if (mode == xyzModem_ymodem) {
       // Note: yModem file name data blocks quietly discarded
       xyz.next_blk = 1;
       xyz.len = 0;
   }
  XMODEM sends the first data block with block number 1. So the
  next block is #2.
- As I understood you do the following:
  The function "xyzModem_get_hdr" receives a data block. If this
  data block is correct, it will be acknowledged by sending an ACK.
  The function "do_load" of module "load.c" receives 512 bytes
  into a buffer (first the data received by function "xyzModem_stream_open"
  are used; if more data requested the function "xyzModem_stream_read"
  will be called).
  First I tried to download SREC files:
  (1) one with approx. 40 characters SREC -> so only one data block (128
bytes)
      will be send
  (2) another with approx. 160 characters SREC -> so two data blocks (each
      128 bytes) will be send
  What happens in case (1):
  The function function "xyzModem_stream_open" receives the only one data
block
  and acknowledge it. The sender then will send the EOT data block.
  The function "do_load" want to fill its 512 bytes buffer. The first 128
bytes
  are get from the data received by function "xyzModem_stream_open" above.
The
  other 128 bytes are get by calling the function "xyzModem_stream_read"
  (EOT data block, which will also be acknowledged). So for the sender the
  protocol is OK.
  What happens in case (1):
  The function function "xyzModem_stream_open" receives the first data block
  and acknowledge it. The sender then will send the second data block.
  The function "do_load" want to fill its 512 bytes buffer. The first 128
bytes
  (first data block) are get from the data received by function
"xyzModem_stream_open"
  above. The other 128 bytes (second data block) are get by calling the
function
  "xyzModem_stream_read" (which will also be acknowledged). Then the sender
will
  send its EOT data block. The function "load_srec_image" will process the
S-Records
  and stop the load command, if it get an address termination record. In
this case
  the EOT data block is not yet acknowledged and the sender cause a protocol
failure.
  Solution: If the function "load_srec_image" get an address termination
record it must
  receive data until the EOT data block is acknowledged.
- There is another problem with the YMODEM protocol. This protocol will
first send
  a file name data block (this will be handled correctly). But before the
EOT data block
  another empty file name data block will be transmitted, which will not be
handled
  and cause a protocol error at the sender side.

NOTE:
What kind of download did you test - only RAW or also SREC?
What terminal application did you use?


Thanks in advance for discussion.

Best regards, Joerg


-----Ursprungliche Nachricht-----
Von: gary@ares.chez-thomas.org [ mailto:gary@ares.chez-thomas.org]Im
Auftrag von Gary Thomas
Gesendet: Dienstag, 7. November 2000 17:11
An: Jorg Rapka
Cc: ecos-discuss@sourceware.cygnus.com
Betreff: RE: [ECOS] redboot



On 07-Nov-2000 Jvrg Rapka wrote:
> Dear ecos developer
>
> I'm very interested in the redboot of ecos.
> I have downloaded the latest version from CVS.
> In the sources I found the information, that
> not only download by TFTP but also xyzmodem
> will be supported (the documentation only
> references TFTP). I compiled the sources
> and tried download by xyzmodem, but it did
> not work so well.
> What is the status of this implementation?
> What was your terminal application and protocol
> used during development tests?

Currently only Ymodem (or Xmodem with CRC) is implemented.

What platform did you try this on?
What problems did you encounter?

It's pretty hard to help much if all you give us is "it did
not work so well."

RE: AW: [ECOS] redboot

[Gary Thomas]

I believe that this has now been fixed.  The changes should arrive in
anonCVS soon.  Anyone interested can contact me privately for the patches.

On 08-Nov-2000 Jorg Rapka wrote:
> Dear Gary
> 
> Sorry for this: "it did not work so well."
> 
> Here are a lot of information!
> 
> My platform is a Motorola 68331.
> 
> What problems did encounter:
> - I'm connected by a serial line with a terminal (COM7.1 from tlgmicro).
>   I start the download process with command "load". Now the character
>   'C' will be send by redboot to start the transmission.
> - I start with XMODEM CRC (use 128 byte per data block). This protocol
>   did not send the file name as first data block. So I get into
>   trouble in function "xyzModem_stream_open".
>   For the YMODEM protocol you ignore this file name data block:
>    // Note: yModem file name data blocks quietly discarded
>    xyz.next_blk = 1;
>    xyz.len = 0;
>   I replaced the above code by this one:
>    if (mode == xyzModem_xmodem) {
>        xyz.next_blk = 2;
>    } else if (mode == xyzModem_ymodem) {
>        // Note: yModem file name data blocks quietly discarded
>        xyz.next_blk = 1;
>        xyz.len = 0;
>    }
>   XMODEM sends the first data block with block number 1. So the
>   next block is #2.
> - As I understood you do the following:
>   The function "xyzModem_get_hdr" receives a data block. If this
>   data block is correct, it will be acknowledged by sending an ACK.
>   The function "do_load" of module "load.c" receives 512 bytes
>   into a buffer (first the data received by function "xyzModem_stream_open"
>   are used; if more data requested the function "xyzModem_stream_read"
>   will be called).
>   First I tried to download SREC files:
>   (1) one with approx. 40 characters SREC -> so only one data block (128
> bytes)
>       will be send
>   (2) another with approx. 160 characters SREC -> so two data blocks (each
>       128 bytes) will be send
>   What happens in case (1):
>   The function function "xyzModem_stream_open" receives the only one data
> block
>   and acknowledge it. The sender then will send the EOT data block.
>   The function "do_load" want to fill its 512 bytes buffer. The first 128
> bytes
>   are get from the data received by function "xyzModem_stream_open" above.
> The
>   other 128 bytes are get by calling the function "xyzModem_stream_read"
>   (EOT data block, which will also be acknowledged). So for the sender the
>   protocol is OK.
>   What happens in case (1):
>   The function function "xyzModem_stream_open" receives the first data block
>   and acknowledge it. The sender then will send the second data block.
>   The function "do_load" want to fill its 512 bytes buffer. The first 128
> bytes
>   (first data block) are get from the data received by function
> "xyzModem_stream_open"
>   above. The other 128 bytes (second data block) are get by calling the
> function
>   "xyzModem_stream_read" (which will also be acknowledged). Then the sender
> will
>   send its EOT data block. The function "load_srec_image" will process the
> S-Records
>   and stop the load command, if it get an address termination record. In
> this case
>   the EOT data block is not yet acknowledged and the sender cause a protocol
> failure.
>   Solution: If the function "load_srec_image" get an address termination
> record it must
>   receive data until the EOT data block is acknowledged.
> - There is another problem with the YMODEM protocol. This protocol will
> first send
>   a file name data block (this will be handled correctly). But before the
> EOT data block
>   another empty file name data block will be transmitted, which will not be
> handled
>   and cause a protocol error at the sender side.
> 
> NOTE:
> What kind of download did you test - only RAW or also SREC?
> What terminal application did you use?
> 
> 
> Thanks in advance for discussion.
> 
> Best regards, Joerg
> 
> 
> -----Ursprungliche Nachricht-----
> Von: gary@ares.chez-thomas.org [ mailto:gary@ares.chez-thomas.org]Im
> Auftrag von Gary Thomas
> Gesendet: Dienstag, 7. November 2000 17:11
> An: Jorg Rapka
> Cc: ecos-discuss@sourceware.cygnus.com
> Betreff: RE: [ECOS] redboot
> 
> 
> 
> On 07-Nov-2000 Jvrg Rapka wrote:
>> Dear ecos developer
>>
>> I'm very interested in the redboot of ecos.
>> I have downloaded the latest version from CVS.
>> In the sources I found the information, that
>> not only download by TFTP but also xyzmodem
>> will be supported (the documentation only
>> references TFTP). I compiled the sources
>> and tried download by xyzmodem, but it did
>> not work so well.
>> What is the status of this implementation?
>> What was your terminal application and protocol
>> used during development tests?
> 
> Currently only Ymodem (or Xmodem with CRC) is implemented.
> 
> What platform did you try this on?
> What problems did you encounter?
> 
> It's pretty hard to help much if all you give us is "it did
> not work so well."