Difference between revisions of "User:Rlatinov"

From REU@MU
Jump to: navigation, search
Line 4: Line 4:
 
== Weekly Log (Summer 2020) ==
 
== Weekly Log (Summer 2020) ==
 
'''Week 1 (01 June - 05 June)'''
 
'''Week 1 (01 June - 05 June)'''
 +
*Preliminary Ideas / Discussion:
 +
:- Audio Processing on the Raspberry Pi
 +
:- Raspberry Pi appears to have built-in facilities to output an audio signal, but not input one
 +
:- Would either have to use an ADC (Analog-to-Digital Converter) to capture a signal (not preferred)
 +
:- or use a USB Microphone (more preferred)
 +
:-
  
 
== Weekly Log (Summer 2017) ==
 
== Weekly Log (Summer 2017) ==

Revision as of 18:31, 4 June 2020

Personal Info

Rade Latinovich is a current student at Marquette University studying Electrical Engineering.

Weekly Log (Summer 2020)

Week 1 (01 June - 05 June)

  • Preliminary Ideas / Discussion:
- Audio Processing on the Raspberry Pi
- Raspberry Pi appears to have built-in facilities to output an audio signal, but not input one
- Would either have to use an ADC (Analog-to-Digital Converter) to capture a signal (not preferred)
- or use a USB Microphone (more preferred)
-

Weekly Log (Summer 2017)

Week 1 (30 May - 4 June)

  • Downloaded a new cross-compiler toolchain (aarch64)
  • I was able to compile sample code found from https://github.com/gingold-adacore/rpi3-fosdem17, with new cross-compiler
  • Modified the sample code to turn on a LED
  • Downloaded simple and watered-down version of Xinu (homework tarball)
- Modified startup.S file in order to be able to boot on RPi3 (did not do anything, but it compiled, and LED turned on)

Week 2 (5 June - 9 June)

  • Started to narrow down on where the code is not working
- Made sure assembly code (start.S) was able to boot
- Then made sure the assembly code can branch to a C method, or some of our C code
  • We were able to make our kernel image boot at the default starting address, this removes the need for us to manually specify where the Pi should boot the image
  • Got "Hello World" through mini UART.. (wrong UART)
  • Started to work on PL011 UART driver
- Biggest difference between PL011 and mini UART is that mini UART's baud rate is partially determined by systems clock frequency, and PL011 has separate reference clock frequency independent from the system clock.
- PL011 uses reference clock frequency determined by BCM2835 Clock Manager
  • We were able to figure out how to control the clock for the GPIO, now we need to do the same thing but for the PL011

Week 3 (12 June - 16 June)

  • Found out default UART clock frequency for Pi 3 is 48 MHz
  • Hacked together a method to initialize the UART hardware in the full version of Xinu
  • Started working on correctly implementing the UART driver in Xinu

Week 4 (19 June - 23 June)

  • Correctly implemented synchronous UART driver in Xinu
  • Started on changing Exception Level (EL) upon boot
- Boots in highest EL (EL 3) and have to be in EL 1 for kernel to run properly
  • Started to work on getting interrupts to work

Week 5 (26 June - 30 June)

  • Figured out Pi 3 boots in EL 2 upon boot
- This is why code was breaking when trying to change ELs
  • Interrupts still not working

Week 6 (3 July - 7 July)

  • Successfully changed EL to EL1
  • Starting to refactor messy code

Week 7 (10 July - 14 July)

  • Decided to use Pi 3 in 32-bit mode
- Compatible with old Pi 1 code
  • IRQ's are working!
- Reaching dispatch() within irq_handler()
- Vector table is set correctly

Week 8 (17 July - 21 July)

  • Added and modified documentation in start.S
  • IRQ's are working successfully and as they should be in Xinu
  • Asynchronous UART works now!
- Tested only printf()
  • Have to have a delay to use printf() immediately after enabling interrupts
  • Cleaned up #define's from beginning of project in initialize.c
  • The System Timer works and clkhandler() is being called properly
  • Preemptive scheduling now works due to interrupts and system timer peripheral working

Week 9 (24 July - 28 July)

  • Starting on working on multicore functionality with Patrick
  • Started researching on mutex's and started to implement mutex lock with ldrex/strex opcodes
  • Found out some weird info about using ldrex/strex opcodes
- Cache and MMU have to be enabled
- ldrex opcode requires memory address to be in cache and marked as shareable by MMU
- Configured MMU with minimal configuration
  • Virtual address are mapped one-to-one with physical addresses
  • Non-peripheral memory space is marked as cache-able and shareable
  • Finished paper and submitted to EWiLi conference for Embedded Systems Week
- Find out if accepted on August 21st

Week 10 (31 July - 4 August)

  • Continued working on mutex lock implementation
- Not working as should across all cores
  • Poster session
  • Final presentation