...
Note |
---|
Bear in mind as well that this description applies to the Gen 1 design. |
Note | |
---|---|
|
Initial instruction
- Execution after reset starts at
0xfffffffc
- A branch instruction (either
b
orba
; 26 bit range) to some boot code is loaded here- The Xilinx example branches to in block RAM (
bram
) at0xffffff00
- The RTEMS example branches to
download_entry
(but I'm not sure how)
- The Xilinx example branches to in block RAM (
- Potentially a
sc
(system call) instruction could be loaded here? Any advantage to this?- Probably not as the corresponding
ivor
register (PPC 440) is not loaded yet - The PPC 405 doesn't have
ivor
registers, so it would continue executing at the system call vector
- Probably not as the corresponding
- A branch instruction (either
dlEntry.s
(download_entry()
)
This file is considered part of an RTEMS BSP and can be found in $RTEMS${RTEMS_ROOT}/src/c/src/lib/libbsp/powerpc/virtex5/dlentry
. What's written here is written for the PPC 440 found in Xilinx Virtex 5 parts. The Virtex 4 version is similar.
- In our case, the boot code starts at
startup
- Other names are
start
,download_entry
and__rtems_entry_point
- Other names are
- Boot code vaguely follows the "Initialization Software Requirements" outlined in the PowerPPC 440x5 Embedded Processor Core User's Manual v7.1 from IBM
- Why only "vaguely"?
- Clear MSR
- Disable debug events
- Configure instruction and data cache registers
- Set up decrementer and timer registers
- Clear exception registers ECR and XER
- Invalidate instruction and data caches
- Clear the CPU reservation bit
- Set up CCR0, CCR1, MMUCR, CRF
and CTR
- Set up TLB pages
- Set up debug events
- Set up EABI and SYSV environment
- Clear out BSS section
- Load vector offset register
- Set up TOC (
overwrites r2?i.e.,
r2
) - Set up initial stack (i.e.,
r1
) - Set up argument registers r3, r4 and r5
- Branch to
boot_card()
...
While the RTEMS structure provides for allowing this function to be supplied by the RTEMS BSP, we use the version that the distribution comes with. It is found in the $RTEMS${RTEMS_ROOT}/src/c/src/lib/libbsp/shared
directory called bootcard.c
.
...
- Command line is in the first and only argument
- In our system this is always a null pointer
- Disable interrupts
- Store command line
- Call
bsp_start()
- Determine RTEMS work area and heap location and size
- Initialize RTEMS data structures
- Initialize the C library
- This also installs the heap
- Call
bsp_pretasking_hook()
\[Enable RTEMS debugging capabilities\]Wiki Markup - RTEMS initialization before loading device drivers
- Call
bsp_predriver_hook()
- Initialize device drivers
- Call
bsp_postdriver_hook()
- Start multitasking
- Before starting the first task call any C++ static constructors.
- Thread with entry point
Init
runs - Not clear how this returns. Perhaps when the last task is deleted?
- Call
bsp_cleanup()
- Return to the start code
- Not clear what's in the
lr
at this point, i.e., where do we return to?
- Not clear what's in the
...
This constitutes our contributions to RTEMS. The code here sets up the processor and board for generic use. Files related to it can be found in $RTEMS${RTEMS_ROOT}/src/c/src/lib/libbsp/powerpc/virtex5/...
}}.
The functions prefixed with app_
are supplied by the RTEMS application, i.e., the RCE project, in our case.
...
- Announce what's running
- Configure the network from DHCP
- Set up the dynamic linker
\[Start the shell\]unmigrated-wiki-markupWiki Markup - \[Start the debugger daemon ({{
gdb
}} stub)\] - Create a
Task
- Determine what the
Task
should run- Read metadata from flash
- Read the front panel rotary switch
- Dynamically link the code
- Run the
Task