Cool.
Also keep in mind that uImage headers have strings identifying what they
contain + crc + other nice properties.
From u-boot/tools/mkimage:
-A ==> set architecture to 'arch'
-O ==> set operating system to 'os'
-T ==> set image type to 'type'
-C ==> set compression type 'comp'
-a ==> set load address to 'addr' (hex)
-e ==> set entry point to 'ep' (hex)
-n ==> set image name to 'name'
And the header costs only 64 bytes...
Ivan
Allred, Daniel wrote:
I'll definitely look into that.
Thanks,
Daniel
Daniel J. Allred
Software Applications
Catalog DSP / Emerging End Equipment
------------------------------------------------------------------------
*From:* Ivan Tonchev [mailto:[EMAIL PROTECTED]
*Sent:* Thursday, March 15, 2007 12:40 PM
*To:* Allred, Daniel
*Cc:* Monk, Roger; Linux DaVinci
*Subject:* Re: UBL for 128MB DDR
OK, great. And just a little suggestion -- if you are in charge of
choosing the binary image header format (to be stored in NAND, NOR,
HDD or whatever medium), why don't you use uImage?
Several months ago I wrote a nand UBL replacement with uImage support
and code for uImage parsing and crc'ing was around 3,7k (~1.8k for
.text and the rest for .rodata) (without the gzip decompression
available in u-boot). Since uImages have standard tools to produce,
you can save your time on generating/parsing headers. Besides uImage
is a recognized brand in bootloading :)
Besides, if you are planning to release your new application sources
to the community (or at to least me :)), I can send you my uImage
parse/crc routines, cut out from u-boot.
Good luck!
Ivan
Allred, Daniel wrote:
Ivan,
If I am able to back port it, it would be simple packets of binary
data with CRC checks. I want to drop the Srec format exactly for the
reasons you mentioned. I can't say more about it right now.
Regards,
Daniel
Daniel J. Allred
Software Applications
Catalog DSP / Emerging End Equipment
------------------------------------------------------------------------
*From:* Ivan Tonchev [mailto:[EMAIL PROTECTED]
*Sent:* Thursday, March 15, 2007 11:53 AM
*To:* Allred, Daniel
*Cc:* Monk, Roger; Linux DaVinci
*Subject:* Re: UBL for 128MB DDR
Great to hear that you'd be dropping the s-rec format. It's bloats
images quite a bit and makes downloads over the UART more slower than
they should be.
What would be the format you'd use? Have you decided yet?
Can you tell us more about the new application you are developing?
Thanks,
Ivan
Allred, Daniel wrote:
Ivan,
Thanks for the suggestions. It's certainly true that the two programs
(the UBL and the host app) can be made more user friendly for porting
to custom boards, as that wasn't the primary goal when I began writing
them. I'm now working on a similar program for the next DaVinci
device, and I have some improvements that I will eventually want to
backport to this software. I will certainly take what you have said
into consideration for future revisions, though I think I will be
doing away with the use of S-records entirely.
Thanks,
Daniel
Daniel J. Allred
Software Applications
Catalog DSP / Emerging End Equipment
------------------------------------------------------------------------
*From:* Ivan Tonchev [mailto:[EMAIL PROTECTED]
*Sent:* Thursday, March 15, 2007 11:04 AM
*To:* Allred, Daniel
*Cc:* Monk, Roger; Linux DaVinci
*Subject:* UBL for 128MB DDR
It'd be also great if you make the UBL more straightforward to port
for boards with less than 256 MB memory.
For current implementation I had to change:
.ddrram2 starting address in ubl_davinci.lds,
MAX_IMAGE_SIZE in ubl.h and
RAM_END_ADDR in ubl.h
For my memory map (128 mb), I set them respectively to 0x84000000,
0x01000000 and 0x87FFFFFF
This could all be done in a single step with a -DRAM_END_ADDR=<desired
size> compiler option if
1) we didn't put gNandTx[] and gNandRx[] as static arrays in
ddrram2, but rather allocated them with ubl_alloc_mem()
2) made ubl_alloc_mem allocate from RAM_END_ADDR downwards, and
not from RAM_START_ADDR upwards
That would:
1) make configuration user friendly
2) obsolete the .ddrram2 section and hence make the
ubl_davinci.lds one for all configurations
3) make S-record decoding more unlikely to fail due to large image
sizes: since we download everything from the end of DDR downwards and
application entry points are usually closer to the start of DDR than
to the end of it.
Anyway, it would be also great if you check whether downloaded
s-record image and decoded binary image areas overlap. Instead of
calling SRecDecode() and waiting it to fail, you can UARTSendData()
something like "Unable to decode srecord. Application load address
falls between downloaded image boundaries"
What do you think?
Ivan
Allred, Daniel wrote:
You are correct. That got left over when I modified the file for
supporting big block devices. The customer tested it on a big block
device so it worked fine.
Thanks. It'll be fixed soon.
Regards,
Daniel
Daniel J. Allred
Software Applications
Catalog DSP / Emerging End Equipment
------------------------------------------------------------------------
begin:vcard
fn:Ivan Tonchev
n:Tonchev;Ivan
org:Multimedia Solutions (MMS);IT
adr:;;Tintiava 15;Sofia;Sofia;1113;Bulgaria
email;internet:[EMAIL PROTECTED]
title:Network Administrator
tel;work:+359 2 868 9186
tel;cell:+359 88 608 9664
url:http://www.mm-sol.com
version:2.1
end:vcard
_______________________________________________
Davinci-linux-open-source mailing list
[email protected]
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
