The Place to Start for Operating System Developers
http://f.osdev.org/
It's actually telling it to link in used functions from the library - very different from linking in the whole library.kzinti wrote:Remove "-lgcc", that's telling gcc to link libgcc in your binrary.ssjcoder wrote: I have no idea what "lib gcc" even is.
Yes that's the theory. In practice I would suggest removing it here and see what happens. libgcc is rarely if ever needed in a baremetal environment. The only one I've hit so far is for 64 bits divisions on ia32 (which can easily be avoided if such is one's desire).Octocontrabass wrote: It's required for code compiled by GCC.
Octocontrabass wrote: Probably not. The linker is smart enough to discard the unused parts of libgcc, which should be most of it.
Indeed. And removing libgcc from the picture could show us unresolved dependencies and move us further along with solving the problem. Right now we do not know if any parts of libgcc is used.iansjack wrote: It's actually telling it to link in used functions from the library - very different from linking in the whole library.
Have you tried copying ALL the kernel files: kernel.img, kernel7.img, kernel8.img? I realize kernel8.img is the one that the Pi 3 should load, but just in case, try all of them.ssjcoder (raspberrypi.org) wrote:However, I can't seem to be able to boot into images, like example, from here: https://github.com/PeterLemon/RaspberryPi
Example, I tried copying kernel8.img from here: https://github.com/PeterLemon/Raspberry ... rot/Double
and it just doesn't go past rainbow screen.
What am I doing wrong?
Thanks, I managed to make it boot from kernel7.img, but this time I made sure to have all the firmware files from https://github.com/raspberrypi/firmware except ".img" files.foliagecanine wrote:Alright, one more thing.
Have you tried copying ALL the kernel files: kernel.img, kernel7.img, kernel8.img? I realize kernel8.img is the one that the Pi 3 should load, but just in case, try all of them.
Did you make sure you had bootcode.bin and start*.elf files? These files are necessary for the Pi to boot as well.
I don't know what they are talking about with checksums (other than perhaps ELF, but that would be a bug in your code). Maybe it is something with the new Raspberry Pi 4 EEPROM firmware, but I don't think the RPi3 is affected.
Code: Select all
kernel_old=1
disable_commandline_tags=1
disable_overscan=1
framebuffer_swap=0Since GCC 10, on aarch64, you need libgcc for basically all __atomic builtins. Using the builtins generates calls to new functions that either implement the atomic op with LDXR/STXR or with new the LSE instructions if they're supported. I'm not entirely sure how it's detected, and if it always involves a branch, but as far as I can tell, you can't tell it to emit LDXR/STXR directly, not without some more involved GCC patching than adding "t-lse t-slibgcc-libgcc" (the latter being needed for libstdc++ to link properly against libgcc.a) to libgcc's configure.host's tmake_file list in your target.kzinti wrote: Yes that's the theory. In practice I would suggest removing it here and see what happens. libgcc is rarely if ever needed in a baremetal environment. The only one I've hit so far is for 64 bits divisions on ia32 (which can easily be avoided if such is one's desire).