[ECOS] Loading executables with ymodem

[ECOS] Loading executables with ymodem

[Nathan J Ickes]

I'm working on two different custom SA-1110 boards. I've been using
GDB successfully with them for a while. 

I now need to be able to store my programs in flash, but I'm having
difficulty with RedBoot's load command. From within Minicom, I issue
the command  

  load -m y

and then tell Minicom to start sending the file. The transfer never
happens...I see lots of NAKs reported, but it's not clear that any
packets are actually ACKed. I've also tried using Hyperterm: again, no
packets are successfully transfered. I do see some 'C's being printed,
presumably from RedBoot trying to initiate the transfer. And after I
kill the transfer (because it's not doing anything), I see some
garbage characters on the command line. If I hit return, RedBoot
complains that <garbage> isn't a valid command. It's like both sides
are trying to make the transfer, but are somehow missing each other.

Looking through the ecos-discuss archives, I see several threads
discussing this sort of problem. None of them, though, offer any fixes
that seem to be applicable. Some older messages mention patches, which
I assume have long since been incorporated into CVS. (I last updated
my sources a few weeks ago.) What is the general status of the RedBoot
load command? I was under the impression that it should just work,
assuming the HAL is in decent order. 

As a final note, I vaguely recall some note about the xyzmodem code
being hardwired to HAL channel 1, either in the source or the
ChangeLog. . Is this true? One of my boards has only one HAL channel:
the SA1110's serial port 2. The other has two channels, the SA1110's
ports 1 and 3.

-- Nathan Ickes

Re: [ECOS] Loading executables with ymodem

[Stefan Eletzhofer]

Am Don, 05 Jul 2001 schrieben Sie:
Hello,
on My SA1110 Assabet Development board downloading via y/xModem and TFTP works
just fine. I also have attached an Neponset daughterboard, which has an
additional serial port. What commandline do you use?

i use:
load -r -b 0x00100000-m yMODEM
for downloading my Linux kernel.


> I'm working on two different custom SA-1110 boards. I've
been using > GDB successfully with them for a while. 
> 
> I now need to be able to store my programs in flash, but I'm having
> difficulty with RedBoot's load command. From within Minicom, I issue
> the command  
> 
>   load -m y
> 
> and then tell Minicom to start sending the file. The transfer never
> happens...I see lots of NAKs reported, but it's not clear that any
> packets are actually ACKed. I've also tried using Hyperterm: again, no
> packets are successfully transfered. I do see some 'C's being printed,
> presumably from RedBoot trying to initiate the transfer. And after I
> kill the transfer (because it's not doing anything), I see some
> garbage characters on the command line. If I hit return, RedBoot
> complains that <garbage> isn't a valid command. It's like both sides
> are trying to make the transfer, but are somehow missing each other.
> 
> Looking through the ecos-discuss archives, I see several threads
> discussing this sort of problem. None of them, though, offer any fixes
> that seem to be applicable. Some older messages mention patches, which
> I assume have long since been incorporated into CVS. (I last updated
> my sources a few weeks ago.) What is the general status of the RedBoot
> load command? I was under the impression that it should just work,
> assuming the HAL is in decent order. 
> 
> As a final note, I vaguely recall some note about the xyzmodem code
> being hardwired to HAL channel 1, either in the source or the
> ChangeLog. . Is this true? One of my boards has only one HAL channel:
> the SA1110's serial port 2. The other has two channels, the SA1110's
> ports 1 and 3.
> 
> -- Nathan Ickes

RE: [ECOS] Loading executables with ymodem

[Gary Thomas]

On 05-Jul-2001 Nathan J Ickes wrote:
> I'm working on two different custom SA-1110 boards. I've been using
> GDB successfully with them for a while. 
> 
> I now need to be able to store my programs in flash, but I'm having
> difficulty with RedBoot's load command. From within Minicom, I issue
> the command  
> 
>   load -m y
> 
> and then tell Minicom to start sending the file. The transfer never
> happens...I see lots of NAKs reported, but it's not clear that any
> packets are actually ACKed. I've also tried using Hyperterm: again, no
> packets are successfully transfered. I do see some 'C's being printed,
> presumably from RedBoot trying to initiate the transfer. And after I
> kill the transfer (because it's not doing anything), I see some
> garbage characters on the command line. If I hit return, RedBoot
> complains that <garbage> isn't a valid command. It's like both sides
> are trying to make the transfer, but are somehow missing each other.
> 

Your problem is most likely the format of the data you are trying to
download.  With the command above, RedBoot will expect to see Motorola
style S-records.  If you send binary or an ELF image, the load will fail.
Sadly, because you are using the debug channel (which RedBoot uses for
messages) to do the loading, you won't get to see the error message as
it will be eaten by your host download code.

Try converting the file to S-records
   arm-elf-objcopy -O srec <ELF-file> <S-rec-file>

> Looking through the ecos-discuss archives, I see several threads
> discussing this sort of problem. None of them, though, offer any fixes
> that seem to be applicable. Some older messages mention patches, which
> I assume have long since been incorporated into CVS. (I last updated
> my sources a few weeks ago.) What is the general status of the RedBoot
> load command? I was under the impression that it should just work,
> assuming the HAL is in decent order. 
> 
> As a final note, I vaguely recall some note about the xyzmodem code
> being hardwired to HAL channel 1, either in the source or the
> ChangeLog. . Is this true? One of my boards has only one HAL channel:
> the SA1110's serial port 2. The other has two channels, the SA1110's
> ports 1 and 3.

On the Assabet, we really only support one serial port - which is
enumerated as "0", but is the hardware UART #1