UBL for 128MB DDR

Allred, Daniel d-allred at ti.com
Thu Mar 15 10:58:05 CST 2007


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:itonchev at mm-sol.com] 
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:itonchev at mm-sol.com] 
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

________________________________






-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://linux.omap.com/pipermail/davinci-linux-open-source/attachments/20070315/11f8d008/attachment-0001.htm


More information about the Davinci-linux-open-source mailing list