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
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
