Difference between revisions of "User:Pbansal"

Latest revision as of 18:52, 27 July 2017

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