Orion U-Boot Porting Notes
From Nas-central-wiki
Contents |
Software
OpenOCD r670 from SVN with the following patch (required to make algorithms work):
diff --git a/src/target/armv4_5.c b/src/target/armv4_5.c
index e546e40..dd818e8 100644
--- a/src/target/armv4_5.c
+++ b/src/target/armv4_5.c
@@ -544,7 +544,7 @@ int armv4_5_run_algorithm(struct target_s *target, int num_mem_params, mem_param
armv4_5->core_cache->reg_list[ARMV4_5_CPSR].valid = 1;
}
- if ((retval = breakpoint_add(target, exit_point, exit_breakpoint_size, BKPT_HARD)) != ERROR_OK)
+ if ((retval = breakpoint_add(target, exit_point, exit_breakpoint_size, BKPT_SOFT)) != ERROR_OK)
{
LOG_ERROR("can't add breakpoint to finish algorithm execution");
return ERROR_TARGET_FAILURE;
GNU gdb (CodeSourcery Sourcery G++ Lite 2007q1-21) 6.6.50.20070320-cvs
Setting up OpenOCD
Config file:
telnet_port 4444 gdb_port 3333 interface ft2232 ft2232_layout "olimex-jtag" ft2232_vid_pid 0x15ba 0x0004 reset_config trst_and_srst jtag_device 4 0x1 0xf 0xe target feroceon little run_and_halt 0
Get the RAM init script
telnet localhost 4444 > reset halt > script kuropro_post_uboot.script
Working with GDB
Connect to the target:
(gdb) target remote localhost:3333
Choose the u-boot (ELF) image
(gdb) file /home/bb3081/project/uboot/testing/davy/u-boot
Load the file onto the target
(gdb) load Loading section .text, size 0x2f0e0 lma 0x0 Loading section .reset_vector_sect, size 0x15c lma 0x30000 Loading section .rodata, size 0x85c lma 0x3015c Loading section .rodata.str1.4, size 0x7664 lma 0x309b8 Loading section .data, size 0x1598 lma 0x3801c Loading section .u_boot_cmd, size 0x524 lma 0x395b4 Loading section .dummy, size 0x10 lma 0xf4c000 Start address 0x0, load size 232392 Transfer rate: 310892 bits/sec, 12231 bytes/write.
GDB will now run normally, continue/next/step will begin execution from the ram image, breakpoints can be set, etc.
U-Boot
- cpu/arm926ejs/start.S
- OLD: has changed some assembly related to malloc
- NEW: CONFIG_SKIP_LOWLEVEL_INIT
- NEW: CONFIG_SKIP_RELOCATE_UBOOT
- OLD jumps to platformsetup, NEW jumps to lowlevel_init (board setup code?)
- OLD: Flush D-cache code not in current U-Boot
Startup
- cpu/arm926ejs/start.S
- PC is set to 0xffff0000 (should be reset vector)
- jumps to reset
- CPU set to SVC32 mode
- jump to cpu_init_crit
- flush v4 I/D caches
- disable MMU stuff and caches, switch to low exception vectors
- jump to lowlevel_init (board specific)
- Compare TEXT_BASE (r1) to _start (r0 - current position of the .text)
- TEXT_BASE is where we want u-boot to end up, _start will be in flash
- if they are not equal:
- _armboot_start == TEXT_BASE into r2 and _bss_start into r3
- r2 = (r3 - r2) + r0 = (_bss_start - TEXT_BASE) + _start = the source end of .text segment
- Copy from r0 (flash) into r1 (TEXT_BASE) until we reach r2
- stack_setup:
- r0 = TEXT_BASE
- r0 -= MALLOC_LEN
- r0 -= CFG_GBL_DATA_SIZE
- r0 -= 12 (abort stack)
- zero the bss segment
- jump to start_armboot
- lib_arm/board.c
- cpu_init() - nothing if interrupts are disabled
- board_init() - TODO
- interrupt_init() - calls timer_init()
- env_init() - depends on where the environment is stored
- init_baudrate()
Halting
Sometimes the kuropro refuses to halt normally, this is most evident when it has an erased flash but it seems to also happen when the lowlevel init isn't run correctly. This is probably caused by Errata 4.1: "ICE-debugger fails to Initalize when All Instructions Fetched are Conditional False of Unsupported"
So far r517 plus the algorithm patch above seems the most reliable. Start the kuropro with just the power button, run openocd, telnet in and tell it to halt. Soon after the microcontroller will kill the power and openocd will falsely report it has halted. Run "arm7_9 dbgrq enable", start the kuropro with the init button pressed and run halt, then reset then halt. Hopefully this will make it halt correctly.
