Difference between revisions of "User:Pbansal"

From REU@MU
Jump to: navigation, search
Line 137: Line 137:
 
Found that value in cpsr register is (in decimal) 5, which is not a mode <br>
 
Found that value in cpsr register is (in decimal) 5, which is not a mode <br>
 
Found, through Stack Overflow, how to change mode <br>
 
Found, through Stack Overflow, how to change mode <br>
 +
Got ctxsw working!!!!!!!!! <br>
 +
Got interrupts working!!!!!!! <br>
 
<br><br>
 
<br><br>
  

Revision as of 19:57, 14 July 2017

Priya.jpg


Marquette Senior

My research project focuses on porting Embedded Xinu into our new, multi-core Raspberry Pi 3s. While my project has just begun, my log thus far is below.

Day 1:
Orientation

Day 2:
Booted Raspbian onto Raspberry Pi 3
Realized Pi is 64 bit and not 32 bit... Got new cross-compiler since old one won't work
Attempted to boot Xinu onto Pi 3 (not yet there)

Day 3:
Got a bare metal program (taken from Tristan Gingold) to boot on the Rasberry Pi and turn on a light

Day 4:
Tried booting a light version of Xinu taken from an old Operating System's homework (didn't work)
Started to convert the code that turned the light on in the C file to assembly (ARM64) to see if the booting process just wasn't getting to the C file

Day 5:
Converted C to assembly using the compiler (which we should have just done before)
Found that booting process wasn't getting to C file but was getting to assembly
Fixed code so light would turn on even when code was in C file
Still not receiving any input from the serial connection

Day 6:
Attended Ethics training

Day 7:
Got serial connection working using mini-UART
Receiving wrong characters using pl011

Day 8:
Tried to find what the correct baud rate should be set to for pl011 (tried being the operative word)

Day 9:
Nothing to see here

Day 10:
Did a lot of research about UART
Found someone online who is a Raspberry Pi developer who got the pl011 driver to work for Raspbian
Attempted to communicate with Pi developer, but didn't receive much helpful information

Day 11:
Got the pl011 driver to work!
Checked to see if receive is also working, and it is

Day 12:
Started looking at and understanding the assembly code in full Xinu
Changed some of the assembly code to work with AArch64
Talked to our mentor about future plans
Started commenting out drivers and other components so that we can start from the bottom

Day 13:
Got full Xinu to print using the serial driver
Did some more AArch64 research
Finally got into really understanding the code in full Xinu

Day 14:
Had a nice talk about future plans
Starting to branch off and do separate work from other group-mates
Learned more about full Xinu code
Started changing context switch

Day 15:
Worked with process creation

Day 16:
Fixed issues with converting test file from light Xinu homework assignment to full Xinu
Found that stack address cannot be referenced

Day 17:
Talked to mentor about importance of removing clutter from code

Day 18:
Worked with new, lighter version of Xinu
Attempted to fix problems with lighter version

Day 19:
Revamped light version so that it works now
Learned about ATAGs and some of the problems we might have with them

Day 20:
Learned about giving a good research presentation
Learned about Device Trees
Attempted to determine whether to use Device Trees over ATAGs

Day 21:
Worked on finding more about ATAGs and Device Trees
Planned presentation for Thursday

Day 22:
Finished presentation
Found that issue with stack address was not with ATAGs
Decided to continue to understand and use ATAGs instead of Device Trees (which we may use later)

Day 23:
Presented

Day 24:
Continued to learn more about ATAGs and how we are receiving information about memory address from them
Determined that firmware may be old or inconsistent (fixup.dat file may not match our start.elf file)

Day 25:
Updated firmware and now receiving expected memsize from ATAGs (close to 1GB)
Changed saddr from ulong pointer to uint pointer and can now assign elements to stack

Day 26:
Found issues with changing saddr from ulong pointer to uint pointer

Day 27:
Decided to keep using uint pointer for saddr
Determined ctxsw not switching processes correctly
Analyzed code to determine where issue could be

Day 28:
Learned more about how ctxsw uses the stack and issues this could create
Worked on project abstract and paper

Day 29:
Narrowed down issue with ctxsw (pointer to saddr pointer is being passed to ctxsw method instead of just the saddr pointer)
Determined that sending the correct parameters to ctxsw causes ctxsw to crash

Day 30:
Worked on abstract and paper

Day 31:
Read other research papers to have a better idea of how to write mine
Changed approach and now trying to run in 32-bit mode
Found ctxsw still does not work 32-bit mode
Attempted to determine why we cannot use the opcode cps (we are presuming it is because we are in unprivileged mode)

Day 32:
Found that value in cpsr register is (in decimal) 5, which is not a mode
Found, through Stack Overflow, how to change mode
Got ctxsw working!!!!!!!!!
Got interrupts working!!!!!!!



Phone: (414) 379-0802

Upgrading Embedded Xinu for the Multi-Core Raspberry Pi 3