Difference between revisions of "User:Pbansal"
| Line 12: | Line 12: | ||
Booted Raspbian onto Raspberry Pi 3 <br> | Booted Raspbian onto Raspberry Pi 3 <br> | ||
Realized Pi is 64 bit and not 32 bit... Found new cross-compiler since old one won't work <br> | Realized Pi is 64 bit and not 32 bit... Found new cross-compiler since old one won't work <br> | ||
| − | Attempted to boot Xinu onto Pi 3 (not yet there) <br> | + | Attempted to boot Xinu onto Pi 3 (not yet there) <br><br> |
Day 3: <br> | Day 3: <br> | ||
| − | Got a bare metal program (taken from Tristan Gingold) to boot on the Rasberry Pi and turn on a light <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: <br> | ||
| − | 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 <br> | + | 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 <br><br> |
Day 5: <br> | Day 5: <br> | ||
| − | Realized over the weekend that our compiler already converts the C code to assembly, so if we just told it not to delete the assembly file we wouldn't have to write the assembly code ourselves... So we tried that today and got it to work. We then moved the code around to see where it stopped working. It worked no matter where we put it in the assembly code, but when we put the code again in the c code that the assembly code branched to, it wouldn't turn the light on. We had the assembly branch to the bare metal c file instead, and the light turned on. So there's something wrong with the original c file <br> | + | Realized over the weekend that our compiler already converts the C code to assembly, so if we just told it not to delete the assembly file we wouldn't have to write the assembly code ourselves... So we tried that today and got it to work. We then moved the code around to see where it stopped working. It worked no matter where we put it in the assembly code, but when we put the code again in the c code that the assembly code branched to, it wouldn't turn the light on. We had the assembly branch to the bare metal c file instead, and the light turned on. So there's something wrong with the original c file <br><br> |
Revision as of 16:25, 5 June 2017
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... Found 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:
Realized over the weekend that our compiler already converts the C code to assembly, so if we just told it not to delete the assembly file we wouldn't have to write the assembly code ourselves... So we tried that today and got it to work. We then moved the code around to see where it stopped working. It worked no matter where we put it in the assembly code, but when we put the code again in the c code that the assembly code branched to, it wouldn't turn the light on. We had the assembly branch to the bare metal c file instead, and the light turned on. So there's something wrong with the original c file
Phone: (414) 379-0802
