From: Gary Thomas <gthomas@redhat.com>
To: Jorg Rapka <joerg.rapka@duagon.com>
Cc: ecos-discuss@sourceware.cygnus.com
Subject: RE: AW: [ECOS] redboot
Date: Mon, 20 Nov 2000 07:38:00 -0000 [thread overview]
Message-ID: <XFMail.20001120083747.gthomas@redhat.com> (raw)
In-Reply-To: <NDBBKEBGMLIMMPMJHHFDOEMOCJAA.joerg.rapka@duagon.com>
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."
prev parent reply other threads:[~2000-11-20 7:38 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-11-07 7:06 Jörg Rapka
2000-11-07 8:10 ` Gary Thomas
2000-11-08 1:06 ` AW: " Jorg Rapka
2000-11-20 7:38 ` Gary Thomas [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=XFMail.20001120083747.gthomas@redhat.com \
--to=gthomas@redhat.com \
--cc=ecos-discuss@sourceware.cygnus.com \
--cc=joerg.rapka@duagon.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).