bf609 , how to boot dual-core application ?

Hello ,

My question : how to boot dual-core application from different location in Flash memory ?

Enviroment : BF609-EZKIT , CCES 1.0.3.0 , emulator 100B or HPUSB-ICE

1. I wrote simple dual-core application , i.e. LED Blink  :

           Core0 - LED 1 and LED 2 on the BF609-EZKIT board

           Core1 - LED 3 and LED 4 on the BF609-EZKIT board

2. My CCES setup for dual core-application (in Post-build steps field)

elfloader.exe -proc ADSP-BF609 -si-revision 0.1 -b MEMORY -f binary -width 16 -bcode 0x01 C:\CCES\App_Core0\Debug\App_Core0.dxe -NoFinalTag C:\CCES\App_Core1\Debug\App_Core1.dxe  -o c:\tftp-root\prog0.ldr

It means that I link 2 *.dxe files into one *.ldr file  (prog0.ldr) . In LdrViewer it is visible as multi-dxe structure (2 dxe blocks) without Final Flag after first block. So it looks good.

3. If I run this application via Emulator : it works OK !!! (both cores OK )

4. If I programmed prog0.ldr file into default location in Flash memory ( 0xb0000000) and press RESET :  it works OK !!!  (both cores OK)

5. If I programmed prog0.ldr file into any different location ( i.e. 0xb0100000 ) and I tried to use rom_Boot () function it DOESN'T WORK !!!

   ( none core doesn't work !!!!)

Example of use rom_Boot()  function below :

#define _BOOTROM_MEMBOOT  0xC800000C

int (*BOOTROM_MEM)(void *, int, int, void *, int , void *) =  (void *) _BOOTROM_MEMBOOT;      // => 0xC800000C

BOOTROM_MEM(0xb0100000 , 0x00, 0 , NULL, 0x01,NULL);    (call rom_BOOT () function !!!)

I checked a lot of argument combinations in the BOOTROM_MEM () function call , but without any success .

6. If I use the same method for booting single-core application it works OK !!!

    (but only when the application doesn't  include InitCode !!! ) .

    The application with InitCode included looks like multi-dxe application ( has got 2 dxe blocks)

    May be it is similar problem ?

So I am surprise why the same file ( prog0.ldr ) works properly from default location but doesn't work from any other ?

I'd like to write a Second Stage Loader Application and I very need this possibility .

Where is the problem ?  Could anybody help me , please ?

Thank you in advance

Jaroslaw

Parents
  • Dear all,

    There is an important followup to what Jaroslaw discovered. To reliably boot Core1 application, Core1 part of bootloader should enter idle state prior to calling MEMBOOT. In my case, it is achieved by CLI folowed by IDLE instruction.

    I believe the explanation is as follows. To boot a dual-core application the Core1 (in a bootloader application) must not be in a reset state (not disabled), othervice all MDMAs to its L1 could not be completed resulting in MEMBOOT process stall. This is probably why single-core bootloader fails to load code to L1 of Core1. A natural attempt to enable Core1 from a bootloader prior loading dual-core application leads to unpredictable results (mostly hanging) because Core1 starts execution from FF600000 where (in single-core bootloader model) no real code is loaded yet. That means Core1 in bootloader should run some sensible code i.e. bootloader itself should be dual-core application.

    On the other hand, Core1 should not read anything from its L1 instruction memory while MDMA fills this L1 with new application code, othervice it could hang (more or less often depending on the structure of Core 1 code). The solution provided in boot ROM  is so-called "Core 1 default application" which is started soon after hardware or JTAG reset and quickly enters idle mode.  While in idle mode Core 1 doesn't read L1 and MDMA to L1 is safe. Unfortunately, it is not possible (as it seems) to start Core 1 default application from software boot call. So, I made a substitute for this default application that also enters idle mode. Such second-stage bootloader works fine.

    Alternatively, it would be possible to find location of Core1 default application in boot ROM and load this address to SVECT1 register prior to enabling Core1 in bootloader. This way a single-core bootloader would work fine. However, Core1 default application address is not documented and not fixed, and most likely will change in the next version of the chip. So, this is a pure hack which is not compatible with future versions of BF60x.

    Unfortunately, there is very little information about dual-core application booting from a second-stage bootloader, so it was very time-consuming to find a solution.

    Regards,

    Peter

Reply
  • Dear all,

    There is an important followup to what Jaroslaw discovered. To reliably boot Core1 application, Core1 part of bootloader should enter idle state prior to calling MEMBOOT. In my case, it is achieved by CLI folowed by IDLE instruction.

    I believe the explanation is as follows. To boot a dual-core application the Core1 (in a bootloader application) must not be in a reset state (not disabled), othervice all MDMAs to its L1 could not be completed resulting in MEMBOOT process stall. This is probably why single-core bootloader fails to load code to L1 of Core1. A natural attempt to enable Core1 from a bootloader prior loading dual-core application leads to unpredictable results (mostly hanging) because Core1 starts execution from FF600000 where (in single-core bootloader model) no real code is loaded yet. That means Core1 in bootloader should run some sensible code i.e. bootloader itself should be dual-core application.

    On the other hand, Core1 should not read anything from its L1 instruction memory while MDMA fills this L1 with new application code, othervice it could hang (more or less often depending on the structure of Core 1 code). The solution provided in boot ROM  is so-called "Core 1 default application" which is started soon after hardware or JTAG reset and quickly enters idle mode.  While in idle mode Core 1 doesn't read L1 and MDMA to L1 is safe. Unfortunately, it is not possible (as it seems) to start Core 1 default application from software boot call. So, I made a substitute for this default application that also enters idle mode. Such second-stage bootloader works fine.

    Alternatively, it would be possible to find location of Core1 default application in boot ROM and load this address to SVECT1 register prior to enabling Core1 in bootloader. This way a single-core bootloader would work fine. However, Core1 default application address is not documented and not fixed, and most likely will change in the next version of the chip. So, this is a pure hack which is not compatible with future versions of BF60x.

    Unfortunately, there is very little information about dual-core application booting from a second-stage bootloader, so it was very time-consuming to find a solution.

    Regards,

    Peter

Children
No Data