[U-Boot-Users] Srec problem and TQM860
Folks,
I have encountered a problem with downloading Linux to my TQM860L board using S records via the serial port. Any help or suggestions would be greatly appreciated.
Last week I followed the ELDK instructions to replace the TQ Monitor on my board with Das U-Boot. I use ELDK 3.0 but download the U-Boot 1.1.1 source and compiled it rather than the 1.0.2 source delivered with ELDK 3.0.
I built U-Boot using
make TQM860L_config
I now realise that I have FEC on my board, and should have used
Make TQM860L_FEC_config
but I did not expect that this would impact on the serial port comms. Perhaps this is the source of the problem ???
I used "cu" on my SuSe 8.2 PC to download U-Boot as SRECs over the serial port.
All of this went well - I can log into U-Boot and execute commands such as flinfo.
I then built the linux 2.4.24 kernel that comes with ELDK 3.0 and converted this to S records. My downloads fail at the seventh S record (see attached debug from "cu" at end of file); record 6 required a retry.
7 cu: fconn_io: Writing 44 "S2140000507800E45A0F701367767FAB3FB6843D4452" cu: fconn_io: Wrote 44 of 44, read 0 of 16383 cu: fconn_io: Writing 1 "\r" cu: fconn_io: Wrote 1 of 1, read 0 of 16383 cu: fconn_read: Read 16 "## S-Record down" <----------- Error starts here cu: fconn_read: Read 8 "load abo" cu: fconn_read: Read 9 "rted\r\n=> "
I have also tried using a RedHat PC which has a different implementation of "cu". The same problem exists.
Has this problem been seen before? Is there anything that can be done to work around it?
Regards and thanks,
Charles.
======================================================================== =
Initial output ==============
U-Boot 1.1.1 (Oct 21 2004 - 11:46:31)
CPU: XPC86xxxZPnnD3 at 50 MHz: 16 kB I-Cache 8 kB D-Cache FEC present Board: TQM860LDB0A3-P50.208 DRAM: 16 MB FLASH: 8 MB In: serial Out: serial Err: serial Net: SCC ETHERNET [PRIME], FEC ETHERNET PCMCIA: No Card found
Type "run flash_nfs" to mount root filesystem over NFS
Hit any key to stop autoboot: 5
=> flinfo
Bank # 1: FUJITSU AM29LV160B (16 Mbit, bottom boot sect) Size: 4 MB in 35 Sectors Sector Start Addresses: 40000000 (RO) 40008000 (RO) 4000C000 (RO) 40010000 (RO) 40020000 (RO) 40040000 40060000 40080000 400A0000 400C0000
400E0000 40100000 40120000 40140000 40160000
40180000 401A0000 401C0000 401E0000 40200000
40220000 40240000 40260000 40280000 402A0000
402C0000 402E0000 40300000 40320000 40340000
40360000 40380000 403A0000 403C0000 403E0000
Bank # 2: FUJITSU AM29LV160B (16 Mbit, bottom boot sect) Size: 4 MB in 35 Sectors Sector Start Addresses: 40400000 40408000 4040C000 40410000 40420000
40440000 40460000 40480000 404A0000 404C0000
404E0000 40500000 40520000 40540000 40560000
40580000 405A0000 405C0000 405E0000 40600000
40620000 40640000 40660000 40680000 406A0000
406C0000 406E0000 40700000 40720000 40740000
40760000 40780000 407A0000 407C0000 407E0000
=> erase 40040000 400fffff
... done Erased 6 sectors => ~[approach].
Output from "loads" ===================
6 cu: fconn_io: Writing 44 "S2140000401F8B0808B40979410203766D6C696E75DA" cu: fconn_io: Wrote 44 of 44, read 0 of 16383 cu: fconn_io: Writing 1 "\r" cu: fconn_io: Wrote 1 of 1, read 0 of 16383 cu: fconn_read: Read 36 "S2140000401F8B0808B40979410036DC9E5A" cu: fconn_read: Read 0 "" R cu: fconn_io: Writing 1 "\025" cu: fconn_io: Wrote 1 of 1, read 0 of 16348 cu: fconn_io: Writing 44 "S2140000401F8B0808B40979410203766D6C696E75DA" cu: fconn_io: Wrote 44 of 44, read 0 of 16383 cu: fconn_io: Writing 1 "\r" cu: fconn_io: Wrote 1 of 1, read 0 of 16383 cu: fconn_read: Read 25 "\025S100401F8B0808B409794102" cu: fconn_read: Read 8 "03766D66" cu: fconn_read: Read 8 "96E75DA\r" 7 cu: fconn_io: Writing 44 "S2140000507800E45A0F701367767FAB3FB6843D4452" cu: fconn_io: Wrote 44 of 44, read 0 of 16383 cu: fconn_io: Writing 1 "\r" cu: fconn_io: Wrote 1 of 1, read 0 of 16383 cu: fconn_read: Read 16 "## S-Record down" <----------- Error starts here cu: fconn_read: Read 8 "load abo" cu: fconn_read: Read 9 "rted\r\n=> " 8 cu: fconn_io: Writing 44 "S214000060C1B230E03F3230D40EAA232E305959C2E6" cu: fconn_io: Wrote 44 of 44, read 0 of 16383 cu: fconn_io: Writing 1 "\r" cu: fconn_io: Wrote 1 of 1, read 0 of 16383 cu: fconn_read: Read 12 "S214000060C1" cu: fconn_read: Read 16 "B230E03F3230D40E" cu: fconn_read: Read 8 "AA232E30" cu: fconn_read: Read 8 "5959C2E6" cu: fconn_read: Read 16 "\r\r\nUnknown comma"
======================================================================== =
Dr Charles J Gillan The Institute of Electronics, Communications and Information Technology (ECIT), Queen's University Belfast, Titanic Quarter Queens Road, Queens Island, Belfast, BT3 9DT Northern Ireland, UK Tel: +44 (0) 2890 971847
In message 002501c4bb53$acc52f20$8a24758f@ee.qub.ac.uk you wrote:
Last week I followed the ELDK instructions to replace the TQ Monitoron my board with Das U-Boot. I use ELDK 3.0 but download the U-Boot 1.1.1 source and compiled it rather than the 1.0.2 source delivered with ELDK 3.0.
Why didn't you use the current code from CVS as recommended in the DULG?
I built U-Boot using
make TQM860L_config
This is OK for recent versions of U-Boot.
I now realise that I have FEC on my board, and should have used
Make TQM860L_FEC_config
Obsolete and does not exist any more.
but I did not expect that this would impact on the serial port comms. Perhaps this is the source of the problem ???
No.
All of this went well - I can log into U-Boot and execute commands such as flinfo.
Then everything is fine.
I then built the linux 2.4.24 kernel that comes with ELDK 3.0 and converted this to S records. My downloads fail at the seventh S record (see attached debug from "cu" at end of file); record 6 required a retry.
Why do you chose the slowest and most unreliable way top download the image? Use TFTP, or at least kermit binary protocol instead.
Has this problem been seen before? Is there anything that can be done to work around it?
Did you configure your UUCP tools as recommended? Are you using a real serial port or one of those crippled USB adapters?
Best regards,
Wolfgang Denk
Thanks, Wolfgang for the response.
I wonder if the problem is my hardware?
My hardware is an STK8xxL.400 Universal Application Baseboard with a TQ minimodule MPC860P/8Mb Flash/16 MB SDRAM. I have connected the serial port on my PC to the "middle" serial port connector on the baseboard. Is this hardware known to cause problems ?
The PC is a Dell Optiplex with SuSe 8.2; it has a serial port on back of the case.
I have also tried to use the "loadb" command (with Kermit on the PC) over the serial port without success. Two packets are sent with 12 retries before Kermit gives up.
I have also tried TFTPBOOT with the following unusual results:
=> tftpboot 40040000 /tftpboot/uImage
Using SCC ETHERNET device TFTP from server 192.168.5.1; our IP address is 192.168.5.6 Filename '/tftpboot/uImage'. Load address: 0x40040000 Loading: *TX timeout TX not ready TX timeout T TX not ready TX timeout T TX not ready TX timeout TX not ready TX timeout T TX not ready TX timeout TX not ready TX timeout T TX not ready TX timeout TX not ready TX timeout T TX not ready TX timeout T TX not ready TX timeout TX not ready TX timeout T TX not ready TX timeout T TX not ready TX timeout T TX not ready TX timeout TX not ready TX timeout T TX not ready TX timeout TX not ready TX timeout
Retry count exceeded; starting again Unable to discover phy!
I note that the "orange link light" is always lit on the baseboard, but that the "green data light" seldom flickers at all.
Does any of this point to a specific kind of problem with my hardware ?
Thanks, again.
Charles.
-----Original Message----- From: u-boot-users-admin@lists.sourceforge.net [mailto:u-boot-users-admin@lists.sourceforge.net] On Behalf Of Wolfgang Denk Sent: 26 October 2004 14:51 To: C.Gillan@ecit.qub.ac.uk Cc: u-boot-users@lists.sourceforge.net Subject: Re: [U-Boot-Users] Srec problem and TQM860
In message 002501c4bb53$acc52f20$8a24758f@ee.qub.ac.uk you wrote:
Last week I followed the ELDK instructions to replace the TQ
Monitor
on my board with Das U-Boot. I use ELDK 3.0 but download the U-Boot 1.1.1 source and compiled it rather than the 1.0.2 source delivered with
ELDK
3.0.
Why didn't you use the current code from CVS as recommended in the DULG?
I built U-Boot using
make TQM860L_config
This is OK for recent versions of U-Boot.
I now realise that I have FEC on my board, and should have used
Make TQM860L_FEC_config
Obsolete and does not exist any more.
but I did not expect that this would impact on the serial port comms. Perhaps this is the source of the problem ???
No.
All of this went well - I can log into U-Boot and execute commands
such
as flinfo.
Then everything is fine.
I then built the linux 2.4.24 kernel that comes with ELDK 3.0 and converted this to S records. My downloads fail at the seventh S record (see attached debug from "cu" at end of file); record 6 required a retry.
Why do you chose the slowest and most unreliable way top download the image? Use TFTP, or at least kermit binary protocol instead.
Has this problem been seen before? Is there anything that can be done
to
work around it?
Did you configure your UUCP tools as recommended? Are you using a real serial port or one of those crippled USB adapters?
Best regards,
Wolfgang Denk
In message 002e01c4bb74$5afd59d0$8a24758f@ee.qub.ac.uk you wrote:
My hardware is an STK8xxL.400 Universal Application Baseboard with a TQ minimodule MPC860P/8Mb Flash/16 MB SDRAM. I have connected the serial port on my PC to the "middle" serial port connector on=20 the baseboard. Is this hardware known to cause problems ?
The TQM8xxL series is one of our reference platofrms. You can be pretty sure that there are no problems.
I have also tried TFTPBOOT with the following unusual results:=> tftpboot 40040000 /tftpboot/uImage
Using SCC ETHERNET device TFTP from server 192.168.5.1; our IP address is 192.168.5.6 Filename '/tftpboot/uImage'. Load address: 0x40040000 Loading: *TX timeout TX not ready TX timeout T TX not ready
...
This is not uinnormal. This is absolutely normal behaviour in case of a misconfiguration of your board, and is actually a FAQ. PLEASE READ THE FAQs _before_ posting. See especially http://www.denx.de/twiki/bin/view/DULG/EthernetProblemsOnTQM8xxL
Does any of this point to a specific kind of problem with my hardware ?
No. I think the hardware is OK, but you didn't jet the jumpers as needed.
Best regards,
Wolfgang Denk
participants (2)
-
Charles J Gillan -
Wolfgang Denk