From mboxrd@z Thu Jan 1 00:00:00 1970 From: Wolfgang Denk Date: Thu, 19 Aug 2010 23:13:36 +0200 Subject: [U-Boot] FW: which protocol do I use to send S-record files when using the loads command ? In-Reply-To: References: <226BC4AFA29FC24789DFD00DFF3084C2524247EECE@SAFEMAIL.safetran.railad.com> <20100819200638.2FD9B157D71@gemini.denx.de> Message-ID: <20100819211336.AC2DC157D71@gemini.denx.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Dear Jef Mangelschots, In message you wrote: > > It is not exactly _parsing_ the record, but storing the decoded data > > to it's final destination, which usually includes flash programming > > cycles. > > Whenever some code takes a ASCII string (in my case an S-record), > extracts fields from it, converts these to numeric values, then I call > that parsing. Me too, but that's not what is taking the time. It is the flash programming cycles. > Kermit protocol works great for us for transferring binary files > (using both Teraterm and Hyperterminal). > It is my understanding that we cannot use Kermit PROTOCOL to transfer > S-record files with loads command. > I though you indicated that in your previous email and it simply > doesn't work when I try. Sorry if I was not clear enough. I always meant to refer to using kermit binary protocol in combinationwith the loadb command. > I am aware that you have suggested in many places AGAINST the use of > S-record, but there is a genuine use for it. > When using U-boot in a non-Linux bareboard embedded system, you need a > way to give your users the capability > to upload now software. An embedded software image is not a 'file' > like in Linux but a memory image where data needs to > reside at fixed addresses. In an multi-megabyte address space, the > 'executable image' can consist of chunks of > data spread over a wide range. 2 options here: (1) create a binary > image of the entire Flash area, (2) a file that specifies which byte > go in which address, i.e. an S-record file. > Option (1) results in a big file with very little. Unless you break it > up in smaller pieces and ask your user to burn image 1 at offset x and > image 2 at offset y, ... You could probably wrap the parts in a FIT image, transfer it in binary mode, and use a script to extract the parts and move them into place. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de A day without sunshine is like night.