Raspberry PI Bare Bones OS

[iansjack]

I have no idea what "lib gcc" even is.

Remove "-lgcc", that's telling gcc to link libgcc in your binrary.

It's actually telling it to link in used functions from the library - very different from linking in the whole library.

[kzinti]

It's required for code compiled by GCC.

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).

Probably not. The linker is smart enough to discard the unused parts of libgcc, which should be most of it.

It's actually telling it to link in used functions from the library - very different from linking in the whole library.

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.

In my experience libgcc is simply not needed here and removing it could help narrow down the problem space. If it isn't the culprit and is indeed needed here, it can always be added back.

What's more, linking libgcc without a cross-compiler is simply wrong and strictly worst than not linking with it. But I see the OP just moved to a cross-compiler.

[ssjcoder]

Thanks guys I will try more tinkering this week if I have time, also, I started topic here: https://www.raspberrypi.org/forums/view ... 2&t=313020

Someone said I might have bad checksum.

IDK how to go from here if I can't boot any images tbh, will try a few things including removing "-lgcc" and post back here.

--thanks for all the help

[foliagecanine]

Alright, one more thing.

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?

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.

[ssjcoder]

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.

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.

Also I made sure to have the "config.txt" properly configured with:

Code: Select all

kernel_old=1
disable_commandline_tags=1
disable_overscan=1
framebuffer_swap=0

I tried messing around with my compiler and it just isn't booting at all (still stuck at rainbow screen).

So, one problem fixed, I can boot into custom kernel7.img, but now I gotta fix my own kernel7.img.

I might just end up using FASMARM once I get my main (Windows 7) machine back if there's no fix on this GCC issue.

--I am open to trying GCC alternatives as long as you know how to configure them for my specific Raspberry PI 3B + device, and you know the exact steps to install required stuff without any fuss, any dependencies/etc (also no building should be required), preferably just one command as I am *not* a linux veteran. (using linux only out of necessity right now)

[qookie]

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).

Since 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.

EDIT: actually, you can disable LSE support and make GCC use LDXR/STXR unconditionally with "-mno-outline-atomics", my bad.