Changes between Version 150 and Version 151 of GSoC/2015

Jun 15, 2015, 6:55:44 AM (4 years ago)
Jarielle Catbagan

Added status update for June 9, 2015


  • GSoC/2015

    v150 v151  
    135135* June 2: During the process of converting the initialization file for running Umon from ROM (rom_reset.S) in the csb740 port to the Beaglebone Black, some existing code were reused as the processor in the csb740 port and the AM335x processor share some similarities.  The reused code encompasses the fundamental and required initializations.  These included retaining the stack initialization for each of the processor modes as well as setting the processor to an initial processor mode, which is supervisor mode.  Right now, I am consolidating the necessary information in order to develop the mechanisms to initialize and set up the external DDR3 RAM on the board. This will provide the capability of removing an application's reliance on the limited internal SRAM  Furthermore, the utilization of this external memory will allow larger images to run on the system.  From the information I was able to obtain it is both practical and efficient in initalizing the external memory at a very low-level, and as a result this process will be done in rom_reset.S.  Shortly after, rom_reset.S jumps to the first C-defined function start().  Mostly like the mechanisms to manipulate the external memory will be done in C.
     137* June 9: The previous Umon image that was built was using the previous Umon 1.19 sources.  The new Umon source tree, which was obtained from the RTEMS git repos, is stripped of any code that would conflict with the licenses involved.  During the process where code was being removed, the directory/file structure of the new Umon source tree was shifted around to the point where a Umon image cannot be built immediately.  After performing the necessary modifications, the basic Umon image that boots from UART and was built from the Umon 1.19 sources can now be built with the new Umon source tree.  I have also looked more extensively in the initialization that Umon undergoes.  Umon does the minimum system intializations with the ultimate goal of presenting the Umon command line to the user.  As mentioned in the previous status update, in the context of the AM335x/Beaglebone Black, program execution first starts at rom_reset.S.  This contains the low-level mechanisms to initialize the system.  From here, a jump to the first C function start() is performed.  The general order of function invocation after start() is umonBssinit() -> init0() -> init1() -> init2() -> reginit() -> init3() before finally reaching CommandLoop() where the Umon command line is presented to the user.  Getting to this point is the main goal.  Since I am approaching the porting process with a top-down approach, the first step would be getting umonBssInit() to function properly.  Delving into the specifics of this function, it can be seen that it manipulates the memory location whose base address is 0x80000000.  Referring to the AM335x TRM, this is the start location of the external DDR3 SDRAM.  As of right now the main focus is performing the necessary configurations to get the external DDR3 SDRAM working before proceeding to modifying the next initialization functions along the chain previously specified.
    137139== Sujay Raj ==