diff options
author | Wojtek Kosior <kwojtus@protonmail.com> | 2019-10-11 19:23:46 +0200 |
---|---|---|
committer | Wojtek Kosior <kwojtus@protonmail.com> | 2019-10-11 19:23:46 +0200 |
commit | 0921cc609a1b411d2b6769a327fa11a675ac3d3a (patch) | |
tree | 0286c9009596a6333fdf410840088558993d6e0f | |
parent | bc9ee9f0acc0ec26acda4ffd8f5fdcd04a6375c5 (diff) | |
download | rpi-MMU-example-0921cc609a1b411d2b6769a327fa11a675ac3d3a.tar.gz rpi-MMU-example-0921cc609a1b411d2b6769a327fa11a675ac3d3a.zip |
list stuff we might otherwise forget to do
-rw-r--r-- | TODOs | 20 |
1 files changed, 20 insertions, 0 deletions
@@ -0,0 +1,20 @@ +* Remove duplications in Makefile... i.e. use generic recipes for .c -> .o compilations and many other things, that can be shortened this was + +* Implement some basic utilities for us to use (memcpy, printf, etc...) + +* ensure .bss section is zeroed properly in stage2 (stage1 and actual kernel do it in common boot.S file; stage2 doesn't use boot.S); Note, that: + - It works as it is right now. If we have no uninitialized static variables in stage2 code, then .bss is probably empty... so this is not really important + - What if wiki.osdev was wrong about this and objcopy includes .bss in it's output image? Then also no work needs to be done + - Stage2 gets loaded between 0x4000 and 0x8000, so that piece of memory could be zeroed-out before by stage1 and that would solve the issue + +* Add sanity-check at build-time, that stage2 blob is smaller than 0x4000 in size + +* Races might occur, when one processor starts overwriting stuff at image load address before other processors execute the initial piece of code that puts them to sleep... This should be fixed in bootloader and will need to be taken into account when we develop the actual kernel to manage it's own memory + +* Real RPi firmware would jump to the kernel on all cores after loading it from SD... So it'd be good if bootloader did a simillar thing - i.e. bootloader, when started, first shuts off all cores but one, it loads it's stage2, which downloads the kernel by uart, turns all cores back on and jumps to kernel on all of them... Additional kudos if U make this race-free (see, TODO above) + +* Finally, the most important thing - move forward and start working with the MMU already! + +* Start doing this on hardware already... (Hey, whole making of a bootloader was with this in mind!) + +* Find a way to pipe kernel through uart (I'm afraid `./pipe_image | screen ...` might not work)
\ No newline at end of file |