2010-02-19 13:51:50     bf527 and LDR

Document created by Aaronwu Employee on Sep 25, 2013
Version 1Show Document
  • View in full screen mode

2010-02-19 13:51:50     bf527 and LDR

Miguel Ángel Álvarez (SPAIN)

Message: 86231   


Dear all


We are trying to use bf527 in a new design. We have some experience on bf537, but we have found that the boot mode is not the same for both DSPs.


As we want to boot from a parallel flash, we have selected BMODE=1 for bf527, and have found that the image we have to program must be in LDR format.


However, we are facing (at least) two different problems:


1. uboot does not add flags for dma and bits for the bf527.


2. ldr seems to place the code in 0xFFA00000 instead of 0x2000000.


What are we missing?


I know that perhaps I am not sending all the required information, but I am not quite sure of what could be required.


Thanks in advance


Miguel ángel




2010-02-19 14:16:01     Re: bf527 and LDR


Message: 86232   




For U-Boot, you should just define "BFIN_BOOT_SPI_MASTER" - and everything else should just work. Is this what you are doing?






2010-02-22 03:47:24     Re: bf527 and LDR

Miguel Ángel Álvarez (SPAIN)

Message: 86308   




I am trying to boot from a parallel flash and not from an SPI master... I am sure you may be right, but... why?




2010-02-22 09:20:14     Re: bf527 and LDR

Miguel Ángel Álvarez (SPAIN)

Message: 86319   


More information...


I have downloaded the precompiled u-boot-bf527-ezkit-para-2009R1.1-rc1.ldr and inspected it with "ldr -qS", obtaining the following.


  DXE 1 at 0x00000000:


              Offset      BlockCode  Address    Bytes      Argument

    Block  1 0x00000000: 0xAD995001 0xFFA00000 0x00000000 0x00036950 ( 8bit-dma-from-8bit ignore first )

    Block  2 0x00000010: 0xADEC0801 0xFFA00000 0x00000134 0xDEADBEEF ( 8bit-dma-from-8bit init )

    Block  3 0x00000154: 0xADC90001 0x03F60000 0x00003E8C 0xDEADBEEF ( 8bit-dma-from-8bit )

    Block  4 0x00003FF0: 0xAD761001 0x00000000 0x00002000 0xBAADF00D ( 8bit-dma-from-8bit ignore )

    Block  5 0x00006000: 0xADFC0001 0x03F63E8C 0x00004174 0xDEADBEEF ( 8bit-dma-from-8bit )

    Block  6 0x0000A184: 0xAD7B0001 0x03F68000 0x00008000 0xDEADBEEF ( 8bit-dma-from-8bit )

    Block  7 0x00012194: 0xADFA0001 0x03F70000 0x00008000 0xDEADBEEF ( 8bit-dma-from-8bit )

    Block  8 0x0001A1A4: 0xAD7A0001 0x03F78000 0x00008000 0xDEADBEEF ( 8bit-dma-from-8bit )

    Block  9 0x000221B4: 0xADF50001 0x03F80000 0x00008000 0xDEADBEEF ( 8bit-dma-from-8bit )

    Block 10 0x0002A1C4: 0xAD750001 0x03F88000 0x00008000 0xDEADBEEF ( 8bit-dma-from-8bit )

    Block 11 0x000321D4: 0xAD170001 0x03F90000 0x00004724 0xDEADBEEF ( 8bit-dma-from-8bit )

    Block 12 0x00036908: 0xADF90001 0xFFA00000 0x00000028 0xDEADBEEF ( 8bit-dma-from-8bit )

    Block 13 0x00036940: 0xAD3B0101 0x03F9474C 0x0006A9C8 0x00000000 ( 8bit-dma-from-8bit fill )

    Block 14 0x00036950: 0xAD738001 0xFFA00000 0x00000000 0x00000000 ( 8bit-dma-from-8bit final )



So it seems it is prepared for booting code from 0xFFA00000 and not from 0x20000000 and using an 8bit flash instead of a 16bit flash (the same I am obtaining for my "from sources" ldr).


I am sure to be missing something, but I am not quite sure what.


Any clues?






2010-02-22 11:30:32     Re: bf527 and LDR


Message: 86326   




If you want to boot from parallel flash - then it is either BFIN_BOOT_BYPASS or BFIN_BOOT_PARA.


Look in include/asm/config-pre.h for the description.






2010-02-22 11:31:29     Re: bf527 and LDR


Message: 86327   




You are confusing the run time address vs storage address.


The storage address doesn't matter for ldr files.






2010-02-22 11:48:17     Re: bf527 and LDR

Miguel Ángel Álvarez (SPAIN)

Message: 86330   


Dear Robin.


Thanks for your answers. I was trying to use "#define CONFIG_BFIN_BOOT_MODE       BFIN_BOOT_PARA".


Ok... So it seems i am mixing storage and program addresses... But... Why are not the same? I mean... my flash is placed in 0x20000000 and my code should run from it... I am wrong?


In the "Direct Code Execution" chapter from the bf527 manual there is an example that show an ldr header with target address 0x20000000 and 0x20000020) for direct booting from flash and not 0xFFA00000.


I am missing something, I know... But I cannot figure what.


BTW... If I check the ARE# in the bf527, I can see four pulses, so it seems it is trying to read four words from the flash... As I do not see any more pulses, I am implying the .ldr is not correct.




Miguel Ángel




2010-02-22 13:11:02     Re: bf527 and LDR

Axel Alatalo (SWEDEN)

Message: 86331   


Chapter 15 of the hwref states:


The internal boot ROM includes a small boot kernel that loads application

data from an external memory or host device. The application data is

expected to be available in a well-defined format, called the boot stream. A

boot stream consists of multiple blocks of data as well as special commands

that instruct the boot kernel on how to initialize on-chip L1

memories as well as off-chip volatile memories.



The boot kernel processes the boot stream block-by-block until it is

instructed by a special command to terminate the procedure and to jump

to the programmable application's start address, which traditionally is at

0xFFA0 0000 in on-chip L1 memory. This process is called “booting.”




I believe the "boot stream" mentioned is the .ldr file. The ldr file is not executable code, it is a bounch of blocks with headers telling the boot-rom where in RAM to put the sections.


u-boot usually want to reside at the end of the ram as you see in your ldr header (all addresses starting with 0x03F60000 =63MB).


You also see that init code is placed at the "traditional" addres 0xFFA0 0000 mentioned in the hwref. Most probably that is where execution will start after the boot-rom is finnished loading.




Now you see the difference. 0x2000 0000 is where the (non executable) .ldr file is located. The other addresses is where the .ldr file is unpacked and finally where execution starts. The ldr file itself is never executed, just unpacked.








2010-02-22 13:52:20     Re: bf527 and LDR

Miguel Ángel Álvarez (SPAIN)

Message: 86336   


Thanks Axel.


I understand what you are trying to explain me... The code is prepared to be executed in 0xFFA00000 whether it is stored or not in flash or whatever...  And it seems you are right as the precompiled images from the u-boot also try to execute 0xFFA00000.


However I have a question... In the hwref when talking about "Flash boot modes", it states that:


"The boot mode BMODE = 0001 can also be used to instruct the boot kernel

to terminate immediately and directly execute code from the 16-bit flash

memory instead. Code execution from 8-bit flash memory is not sup-

ported. See “Direct Code Execution” on page 15-35 for details."


Going to the "Direct Code Execution", I find that:


"For example in BMODE = 1, when the block header described in Table 15-6

on page 15-36 is placed at address 0x2000 0000, the boot kernel is

instructed to issue a JUMP command to address 0x2000 0020.


The development tools must be instructed to link the above block to

address 0x2000 0000 and the application code to address 0x2000 0020.

An example shown in “Direct Code Execution” on page 15-117 illustrates

how this is accomplished using VisualDSP++ tools suite.


Table 15-6. Initial Header for Direct Code Execution in BMODE = 1

Field             Value       Comments

BLOCK CODE        0xAD7B D006 0xAD00 0000 | XORSUM |

                              BFLAG_FINAL | BFLAG_FIRST | BFLAG_IGNORE |

                              (DMACODE & 0x6)

TARGET ADDRESS 0x2000 0020    Start address of application code

BYTE COUNT        0x0000 0010 Ignores 16 bytes to provide space for control data such as

                              version code and build data. This is optional and can be


ARGUMENT          0x0000 0010 Functions as next-DXE pointer in multi-DXE boot





So... why is this? Am I using the wrong mode (BMODE=0001)?




Miguel Ángel




2010-02-22 14:45:32     Re: bf527 and LDR

Axel Alatalo (SWEDEN)

Message: 86337   


When I started reading this thread I was initially a bit puzzled to why you use .ldr file to boot from PFLASH. I then realized that the "BYPASS" boot-mode from BF53X (which is the processor I'm by far most familiar with) does not exist in BF527. BF537 hwref states on page 19-35:


In bypass mode (BMODE = 000), the processor starts code execution from

address 0x2000 0000. This is the first address in the asynchronous memory

bank 0.


While BF527 manual states:


The no-boot mode is not the same as the bypass mode featured by

the ADSP-BF53x processor. To simulate that bypass mode feature

using BMODE = 0000, see “Direct Code Execution” on page 15-35

and “Direct Code Execution” on page 15-117.


On BF537 you can use the .bin file (Not the .ldr) and just program it to 0x2000 0000. The .bin file contains a loader which loads u-boot to its final destination in RAM. If you really want to emulate that behaviour you can read page 15-35. However I don't think that is what you want.


I don't know if u-boot can execute from flash, but even if its possible, I cannot se why you would like to do that (note that even in BYPASS mode on 53x u-boot is loaded to RAM before execution, it  is just the loader that is executed from flash).


To make a long story short: I believe that what you want to do is have the bfin boot-rom unpack the standard u-boot .ldr file from PFLASH (0x2000 0000), and in that case your boot mode (001) seems correct.


Why doesn't it work? The boot rom first loads 4 words of header to try to decide the following loading. As you states the 4 initial reads indicates that the boot-rom does not understand what it is reading and stops


* Have you verified that the file is correctly written to PFLASH? The jtag may come in handy here, ICEBEAR+gdbproxy+gdb you can dump bfin memory (rememver PFLASH is memory mapped) to you local disk on your PC and compare to what you expect to find.


* Is the board hardware verified?



I see something strange in the manuals that I dont understand maybe Robin knows?


The bf527 datasheet states:


Idle/no boot mode (BMODE = 0x0) — In this mode, the

processor goes into idle. The idle boot mode helps recover

from illegal operating modes, such as when the OTP memory

has been misconfigured.



(BMODE = 0x1) — In this mode, the boot kernel loads the

first block header from address 0x2000 0000, and (depending

on instructions contained in the header) the boot

kernel performs an 8- or 16-bit boot or starts program execution

at the address provided by the header.


While page 15-61 in the hwref states:


The flash boot modes are

activated by BMODE = 0000


And page 15-63 in the hwref states


The boot mode BMODE = 0001 can also be used to instruct the boot kernel

to terminate immediately and directly execute code from the 16-bit flash

memory instead.


This don't make sense to me, pages 15-61, and 15-63 seems to contradict the datasheet and even other places in the hwref.




2010-02-22 15:13:15     Re: bf527 and LDR


Message: 86340   




All the manuals are correct.


Boot mode 0 does not mean the same on all blackfins, in fact most do not use the same pin strapping.




Execute in place ( Bypass Boot ROM - or Execution starts from address 0x20000000) - bmode 0 on some - is not on all.


Others only support LDR boots. Because many people complained that this sucked, the people who wrote the bootrom came up with a workaround that the ldr could just jump to to 0x200000020 - or some other arbartary address. This is not a bypass mode - since it requires that the bootrom still boot. It is just a specific LDR example.


Since you are required to use LDR on some - there is no advantage from U-Boot's perspective from having the Bootrom do the relocation from Flash to external memory, or having U-Boot do it. So on those parts - we don't support this wonky, poorly documented (or we wouldn't be having this discussion) LDR format which the manuals sometime refer to as execute in place.


If you know what they mean, you can see why things were written the way they were written - but they don't explain things well... To paraphrase...


bootmode 0 (execute the IDLE instruction), is activated by BMODE 0000.


You can make a LDR which terminates immediately, and jumps to an address in flash, and use bootmode 1 (BMODE 0001), to approximate a execute in place.






2010-02-22 15:27:32     Re: bf527 and LDR

Axel Alatalo (SWEDEN)

Message: 86345   


Hi Robin,


The appearant discepencies were between bf527 hwref and bf527 datasheet, It was just in the beginning I made one single reference to bf537.


Anyway, thanks fot your answer, I now understand what hw 15-63 refers to. However I still dont understand how hw15-61 in the bf527 can state:


The flash boot modes are

activated by BMODE = 0000


while for example 15-60 states:


When the BMODE pins are all tied low (BMODE = 0000), the Blackfin processor

does not boot.


I believe 15-61 is a typo and should say 0001 instead.






2010-02-22 15:29:30     Re: bf527 and LDR

Mike Frysinger (UNITED STATES)

Message: 86346   


i dont know what you mean when you say:


    1. uboot does not add flags for dma and bits for the bf527.


you'll need to clarify




2010-02-22 15:31:31     Re: bf527 and LDR

Mike Frysinger (UNITED STATES)

Message: 86347   


datasheet/HRM corrections go through analog.com.  either the processor support e-mails (as found in the datasheet/HRM) or the web forum over there.


considering new HRMs are simply taken from previous ones and tweaked, it isnt surprising that an old reference slipped through.




2010-02-23 13:24:11     Re: bf527 and LDR

Miguel Ángel Álvarez (SPAIN)

Message: 86393   


Thanks for all your answers...


Yes... I should have stated that bf527 boot modes were not the same as bf537 ones... And that I was not quite sure about some inconsistencies between BMODE=0000 and BMODE=0001.


I am sorry Robin, but I do not have quite understood your explanation.


My intention is not trying to do anything strange with the u-boot, but just trying to boot it from RAM (and have it stored in Flash).


So... In this case... What should be the mode? BMODE=0000 or BMODE=0001?


And the LDR... is it just fine as it is build for 0xFFA00000?


I suppose that although it has to run in RAM, if I had a correct header in 0x20000000 it should do more that four readings (at least to read the first lines of code and place them in L1, not?)


Thanks a lot for all your help.




2010-02-23 13:35:44     Re: bf527 and LDR

Miguel Ángel Álvarez (SPAIN)

Message: 86394   


Sorry Mike


About the flags...


For example in board/bf533-ezkit/config.mk we have LDR_FLAGS-BFIN_BOOT_PARA := --bits 16 --dma 8


However for bf527ezkit we are not stating the bits and dma, so the LDR headers always do not inform that we are dealing with a 16bit flash... Am I wrong?




Miguel Ángel




2010-02-23 19:02:23     Re: bf527 and LDR

Mike Frysinger (UNITED STATES)

Message: 86406   


stop worrying about the addresses in the LDR file relative to the flash/L1.  everything you've shown from the LDR looks correct.




2010-02-23 19:04:22     Re: bf527 and LDR

Mike Frysinger (UNITED STATES)

Message: 86407   


it probably could be changed to do 16bit dma from 16bit, but the current LDR boots fine, so no one has really cared.  i can take a look when i get back to the US.




2010-02-26 13:30:27     Re: bf527 and LDR

Miguel Ángel Álvarez (SPAIN)

Message: 86613   


OK. It is working. I was thinking that the BMODE pins had internal pullups... So I really was selecting BMODE=0000 all the time.