Difference between revisions of "User:Pbansal"

From REU@MU
Jump to: navigation, search
 
(11 intermediate revisions by the same user not shown)
Line 4: Line 4:
 
'''Marquette Senior'''
 
'''Marquette Senior'''
 
<br><br>
 
<br><br>
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. <br><br>
+
My research project focuses on porting Embedded Xinu into our new, multi-core Raspberry Pi 3s.  This project will greatly help students in Marquette University and universities across the world learn multi-core concepts using an easy-to-understand, light-weight operating system.  My log for this project is below. <br><br>
  
Day 1: <br>
+
Day 1 (05/30/17): <br>
 
Orientation <br><br>
 
Orientation <br><br>
  
Day 2: <br>
+
Day 2 (05/31/17): <br>
 
Booted Raspbian onto Raspberry Pi 3 <br>
 
Booted Raspbian onto Raspberry Pi 3 <br>
 
Realized Pi is 64 bit and not 32 bit... Got new cross-compiler since old one won't work <br>
 
Realized Pi is 64 bit and not 32 bit... Got new cross-compiler since old one won't work <br>
 
Attempted to boot Xinu onto Pi 3 (not yet there) <br><br>
 
Attempted to boot Xinu onto Pi 3 (not yet there) <br><br>
  
Day 3: <br>
+
Day 3 (06/01/17): <br>
 
Got a bare metal program (taken from Tristan Gingold) to boot on the Rasberry Pi and turn on a light <br><br>
 
Got a bare metal program (taken from Tristan Gingold) to boot on the Rasberry Pi and turn on a light <br><br>
  
Day 4: <br>
+
Day 4 (06/02/17): <br>
 
Tried booting a light version of Xinu taken from an old Operating System's homework (didn't work) <br>
 
Tried booting a light version of Xinu taken from an old Operating System's homework (didn't work) <br>
 
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 <br><br>
 
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 <br><br>
  
Day 5: <br>
+
Day 5 (06/05/17): <br>
 
Converted C to assembly using the compiler (which we should have just done before) <br>
 
Converted C to assembly using the compiler (which we should have just done before) <br>
 
Found that booting process wasn't getting to C file but was getting to assembly <br>
 
Found that booting process wasn't getting to C file but was getting to assembly <br>
Line 27: Line 27:
 
Still not receiving any input from the serial connection<br><br>
 
Still not receiving any input from the serial connection<br><br>
  
Day 6: <br>
+
Day 6 (06/06/17): <br>
 
Attended Ethics training<br><br>
 
Attended Ethics training<br><br>
  
Day 7: <br>
+
Day 7 (06/07/17): <br>
 
Got serial connection working using mini-UART <br>
 
Got serial connection working using mini-UART <br>
 
Receiving wrong characters using pl011<br><br>
 
Receiving wrong characters using pl011<br><br>
  
Day 8: <br>
+
Day 8 (06/08/17): <br>
 
Tried to find what the correct baud rate should be set to for pl011 (tried being the operative word)<br><br>
 
Tried to find what the correct baud rate should be set to for pl011 (tried being the operative word)<br><br>
  
Day 9: <br>
+
Day 9 (06/09/17): <br>
 
Nothing to see here<br><br>
 
Nothing to see here<br><br>
  
Day 10: <br>
+
Day 10 (06/12/17): <br>
 
Did a lot of research about UART <br>
 
Did a lot of research about UART <br>
 
Found someone online who is a Raspberry Pi developer who got the pl011 driver to work for Raspbian <br>
 
Found someone online who is a Raspberry Pi developer who got the pl011 driver to work for Raspbian <br>
 
Attempted to communicate with Pi developer, but didn't receive much helpful information<br><br>
 
Attempted to communicate with Pi developer, but didn't receive much helpful information<br><br>
  
Day 11: <br>
+
Day 11 (06/13/17): <br>
 
Got the pl011 driver to work! <br>
 
Got the pl011 driver to work! <br>
 
Checked to see if receive is also working, and it is<br><br>
 
Checked to see if receive is also working, and it is<br><br>
  
Day 12: <br>
+
Day 12 (06/14/17): <br>
 
Started looking at and understanding the assembly code in full Xinu <br>
 
Started looking at and understanding the assembly code in full Xinu <br>
 
Changed some of the assembly code to work with AArch64 <br>
 
Changed some of the assembly code to work with AArch64 <br>
Line 55: Line 55:
 
Started commenting out drivers and other components so that we can start from the bottom<br><br>
 
Started commenting out drivers and other components so that we can start from the bottom<br><br>
  
Day 13: <br>
+
Day 13 (06/15/17): <br>
 
Got full Xinu to print using the serial driver <br>
 
Got full Xinu to print using the serial driver <br>
 
Did some more AArch64 research <br>
 
Did some more AArch64 research <br>
 
Finally got into really understanding the code in full Xinu<br><br>
 
Finally got into really understanding the code in full Xinu<br><br>
  
Day 14: <br>
+
Day 14 (06/16/17): <br>
 
Had a nice talk about future plans <br>
 
Had a nice talk about future plans <br>
 
Starting to branch off and do separate work from other group-mates <br>
 
Starting to branch off and do separate work from other group-mates <br>
Line 66: Line 66:
 
Started changing context switch<br><br>
 
Started changing context switch<br><br>
  
Day 15: <br>
+
Day 15 (06/19/17): <br>
 
Worked with process creation<br><br>
 
Worked with process creation<br><br>
  
Day 16: <br>
+
Day 16 (06/20/17): <br>
 
Fixed issues with converting test file from light Xinu homework assignment to full Xinu <br>
 
Fixed issues with converting test file from light Xinu homework assignment to full Xinu <br>
 
Found that stack address cannot be referenced<br><br>
 
Found that stack address cannot be referenced<br><br>
  
Day 17: <br>
+
Day 17 (06/21/17): <br>
 
Talked to mentor about importance of removing clutter from code<br><br>
 
Talked to mentor about importance of removing clutter from code<br><br>
  
Day 18: <br>
+
Day 18 (06/22/17): <br>
 
Worked with new, lighter version of Xinu <br>
 
Worked with new, lighter version of Xinu <br>
 
Attempted to fix problems with lighter version<br><br>
 
Attempted to fix problems with lighter version<br><br>
  
Day 19: <br>
+
Day 19 (06/23/17): <br>
 
Revamped light version so that it works now <br>
 
Revamped light version so that it works now <br>
 
Learned about ATAGs and some of the problems we might have with them<br><br>
 
Learned about ATAGs and some of the problems we might have with them<br><br>
  
Day 20: <br>
+
Day 20 (06/26/17): <br>
 
Learned about giving a good research presentation <br>
 
Learned about giving a good research presentation <br>
 
Learned about Device Trees <br>
 
Learned about Device Trees <br>
 
Attempted to determine whether to use Device Trees over ATAGs<br><br>
 
Attempted to determine whether to use Device Trees over ATAGs<br><br>
  
Day 21: <br>
+
Day 21 (06/27/17): <br>
 
Worked on finding more about ATAGs and Device Trees <br>
 
Worked on finding more about ATAGs and Device Trees <br>
 
Planned presentation for Thursday<br><br>
 
Planned presentation for Thursday<br><br>
  
Day 22: <br>
+
Day 22 (06/28/17): <br>
 
Finished presentation <br>
 
Finished presentation <br>
 
Found that issue with stack address was not with ATAGs <br>
 
Found that issue with stack address was not with ATAGs <br>
 
Decided to continue to understand and use ATAGs instead of Device Trees (which we may use later)<br><br>
 
Decided to continue to understand and use ATAGs instead of Device Trees (which we may use later)<br><br>
  
Day 23: <br>
+
Day 23 (06/29/17): <br>
 
Presented<br><br>
 
Presented<br><br>
  
Day 24: <br>
+
Day 24 (06/30/17): <br>
 
Continued to learn more about ATAGs and how we are receiving information about memory address from them <br>
 
Continued to learn more about ATAGs and how we are receiving information about memory address from them <br>
 
Determined that firmware may be old or inconsistent (fixup.dat file may not match our start.elf file)<br><br>
 
Determined that firmware may be old or inconsistent (fixup.dat file may not match our start.elf file)<br><br>
  
Day 25: <br>
+
Day 25 (07/05/17): <br>
 
Updated firmware and now receiving expected memsize from ATAGs (close to 1GB) <br>
 
Updated firmware and now receiving expected memsize from ATAGs (close to 1GB) <br>
 
Changed saddr from ulong pointer to uint pointer and can now assign elements to stack<br><br>
 
Changed saddr from ulong pointer to uint pointer and can now assign elements to stack<br><br>
  
Day 26: <br>
+
Day 26 (07/06/17): <br>
 
Found issues with changing saddr from ulong pointer to uint pointer<br><br>
 
Found issues with changing saddr from ulong pointer to uint pointer<br><br>
  
Day 27: <br>
+
Day 27 (07/07/17): <br>
 
Decided to keep using uint pointer for saddr <br>
 
Decided to keep using uint pointer for saddr <br>
 
Determined ctxsw not switching processes correctly <br>
 
Determined ctxsw not switching processes correctly <br>
 
Analyzed code to determine where issue could be<br><br>
 
Analyzed code to determine where issue could be<br><br>
  
Day 28: <br>
+
Day 28 (07/10/17): <br>
 
Learned more about how ctxsw uses the stack and issues this could create <br>
 
Learned more about how ctxsw uses the stack and issues this could create <br>
 
Worked on project abstract and paper<br><br>
 
Worked on project abstract and paper<br><br>
  
Day 29: <br>
+
Day 29 (07/11/17): <br>
 
Narrowed down issue with ctxsw (pointer to saddr pointer is being passed to ctxsw method instead of just the saddr pointer) <br>
 
Narrowed down issue with ctxsw (pointer to saddr pointer is being passed to ctxsw method instead of just the saddr pointer) <br>
 
Determined that sending the correct parameters to ctxsw causes ctxsw to crash<br><br>
 
Determined that sending the correct parameters to ctxsw causes ctxsw to crash<br><br>
  
Day 30: <br>
+
Day 30 (07/12/17): <br>
 
Worked on abstract and paper<br><br>
 
Worked on abstract and paper<br><br>
  
Day 31: <br>
+
Day 31 (07/13/17): <br>
 
Read other research papers to have a better idea of how to write mine <br>
 
Read other research papers to have a better idea of how to write mine <br>
 
Changed approach and now trying to run in 32-bit mode <br>
 
Changed approach and now trying to run in 32-bit mode <br>
Line 134: Line 134:
 
Attempted to determine why we cannot use the opcode cps (we are presuming it is because we are in unprivileged mode)<br><br>
 
Attempted to determine why we cannot use the opcode cps (we are presuming it is because we are in unprivileged mode)<br><br>
  
Day 32: <br>
+
Day 32 (07/14/17): <br>
 
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 ctxsw working!!!!!!!!! <br>
 
Got interrupts working!!!!!!! <br>
 
Got interrupts working!!!!!!! <br>
<br><br>
+
Found that null user was continuously running <br>
 +
Fixed continuous loop issue by taking out code that dealt with interrupts in halt.S<br><br>
  
 +
Day 33 (07/17/17): <br>
 +
Worked on USB Driver <br>
 +
Tried to determine whether USB Driver was recognizing input <br>
 +
USB Driver did not seem to be recognizing input<br><br>
 +
 +
Day 34 (07/18/17): <br>
 +
Worked simultaneously on USB Driver and multi-cores to see which problem better suited me <br>
 +
Decided to continue work on multi-cores <br>
 +
Had talk about how to split up posters <br>
 +
Had talk about how to approach multi-core problem once we had multiple cores running expected code<br><br>
 +
 +
Day 35 (07/19/17): <br>
 +
Attempted to run multiple cores <br>
 +
Determined that all cores were running, but 3 of the 4 cores were "parked" <br>
 +
Attempted to "unpark" the cores, to no avail<br><br>
 +
 +
Day 36 (07/20/17): <br>
 +
Still trying to unpark cores 1-3 <br>
 +
Others have also faced the issue we're facing, so problem may be with the current information that's out there <br>
 +
It seems that I can't write to the mailboxes that control where cores 1-3 start running<br><br>
 +
 +
Day 37 (07/21/17): <br>
 +
Got multiple cores printing at the same time!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!<br><br>
 +
 +
Day 38 (07/24/17): <br>
 +
Organized code over the weekend <br>
 +
Attempted to create a token system (mildly successful) for instructing the cores to print one at a time <br>
 +
Realized there was an issue with context switching in cores 1-3 since these cores, like core 0, start in unprivileged mode <br>
 +
Fix for this issue for core 0 didn't seem to be working for cores 1-3<br><br>
 +
 +
Day 39 (07/25/17): <br>
 +
Worked more with tokens, this time with context switch working for cores 1-3 <br>
 +
Cores 1 and 2 still printed simultaneously using token method, but core 3 printed separately <br>
 +
Worked on poster<br><br>
 +
 +
Day 40 (07/26/17): <br>
 +
Worked on poster<br><br>
 +
 +
Day 41 (07/27/17): <br>
 +
Worked on research paper for EWiLi Conference<br><br>
  
  

Latest revision as of 18:52, 27 July 2017

Priya.jpg


Marquette Senior

My research project focuses on porting Embedded Xinu into our new, multi-core Raspberry Pi 3s. This project will greatly help students in Marquette University and universities across the world learn multi-core concepts using an easy-to-understand, light-weight operating system. My log for this project is below.

Day 1 (05/30/17):
Orientation

Day 2 (05/31/17):
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 (06/01/17):
Got a bare metal program (taken from Tristan Gingold) to boot on the Rasberry Pi and turn on a light

Day 4 (06/02/17):
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 (06/05/17):
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 (06/06/17):
Attended Ethics training

Day 7 (06/07/17):
Got serial connection working using mini-UART
Receiving wrong characters using pl011

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

Day 9 (06/09/17):
Nothing to see here

Day 10 (06/12/17):
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 (06/13/17):
Got the pl011 driver to work!
Checked to see if receive is also working, and it is

Day 12 (06/14/17):
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 (06/15/17):
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 (06/16/17):
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 (06/19/17):
Worked with process creation

Day 16 (06/20/17):
Fixed issues with converting test file from light Xinu homework assignment to full Xinu
Found that stack address cannot be referenced

Day 17 (06/21/17):
Talked to mentor about importance of removing clutter from code

Day 18 (06/22/17):
Worked with new, lighter version of Xinu
Attempted to fix problems with lighter version

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

Day 20 (06/26/17):
Learned about giving a good research presentation
Learned about Device Trees
Attempted to determine whether to use Device Trees over ATAGs

Day 21 (06/27/17):
Worked on finding more about ATAGs and Device Trees
Planned presentation for Thursday

Day 22 (06/28/17):
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 (06/29/17):
Presented

Day 24 (06/30/17):
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 (07/05/17):
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 (07/06/17):
Found issues with changing saddr from ulong pointer to uint pointer

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

Day 28 (07/10/17):
Learned more about how ctxsw uses the stack and issues this could create
Worked on project abstract and paper

Day 29 (07/11/17):
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 (07/12/17):
Worked on abstract and paper

Day 31 (07/13/17):
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 (07/14/17):
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!!!!!!!
Found that null user was continuously running
Fixed continuous loop issue by taking out code that dealt with interrupts in halt.S

Day 33 (07/17/17):
Worked on USB Driver
Tried to determine whether USB Driver was recognizing input
USB Driver did not seem to be recognizing input

Day 34 (07/18/17):
Worked simultaneously on USB Driver and multi-cores to see which problem better suited me
Decided to continue work on multi-cores
Had talk about how to split up posters
Had talk about how to approach multi-core problem once we had multiple cores running expected code

Day 35 (07/19/17):
Attempted to run multiple cores
Determined that all cores were running, but 3 of the 4 cores were "parked"
Attempted to "unpark" the cores, to no avail

Day 36 (07/20/17):
Still trying to unpark cores 1-3
Others have also faced the issue we're facing, so problem may be with the current information that's out there
It seems that I can't write to the mailboxes that control where cores 1-3 start running

Day 37 (07/21/17):
Got multiple cores printing at the same time!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Day 38 (07/24/17):
Organized code over the weekend
Attempted to create a token system (mildly successful) for instructing the cores to print one at a time
Realized there was an issue with context switching in cores 1-3 since these cores, like core 0, start in unprivileged mode
Fix for this issue for core 0 didn't seem to be working for cores 1-3

Day 39 (07/25/17):
Worked more with tokens, this time with context switch working for cores 1-3
Cores 1 and 2 still printed simultaneously using token method, but core 3 printed separately
Worked on poster

Day 40 (07/26/17):
Worked on poster

Day 41 (07/27/17):
Worked on research paper for EWiLi Conference


Phone: (414) 379-0802

Upgrading Embedded Xinu for the Multi-Core Raspberry Pi 3