ARM cp15 c1 control on the BBB at _start

[Chris Johns]

Hi,

I have a recent git master build of OpenOCD loading an RTEMS executable and it
runs without error until `bsp_reset` where it stops on a break point. I however
cannot step cleanly if I set a break point on `Init` and I am looking into this.
To start with I am looking at the MMU and cache set ups.

I wanted to see what state the ARM is in when it enters RTEMS so I added:

 mrc  p15, 0, r3, c1, c0, 0

and:

 (gdb) p /x $r3
 $1 = 0xc5187a
 (gdb) p /t $r3
 $2 = 110001010001100001111010

This aligns with OpenOCD's view:

 MMU: disabled, D-Cache: disabled, I-Cache: enabled

What concerns me is the A flag (bit 1) is set and it stays set until the BBB
specific MMU is set up.

Is this on purpose and does this means there are strict requirements on the code
that can be called? For example I see there is `bsp_start_memcpy` and the
comment discusses this?

Note, the Zynq does not clear the A flag in it's specific MMU set up call so
does it assume the boot loader will clear it?

Why not clear the A flag and remove any restrictions and try and make the BSPs
consistent?

The OpenOCD set up is:

  mon echo "] Reset..."
  mon reset halt
  mon bp 0x402f0400 4 hw
  mon reset run
  mon sleep 1000
  mon rbp 0x402f0400
  mon echo "] Loading MLO"
  mon load_image /opt/src/rtems/beagle/black/u-boot-spl-nodtb.bin 0x402f0400 bin
  mon bp 0x402f1424 4 hw
  mon echo "] Resume 0x402f0400"
  mon resume 0x402f0400
  mon sleep 1000
  mon rbp 0x402f1424
  mon echo "] Done ..."

The procedure is:

 1. Set a hardware break point on the entry point called by the ROM. This lets
    the ROM code initialise the CPU including disabling the watchdog.
 2. Load the U-Boot SPL code into the SRAM.
 3. Set a break point to the instruction after the call to `board_init_f`. The
    DRAM will be initialised.
 4. Run the SPL code.

After this the RTEMS application can be loaded by GDB and run.

Chris