Hacker News new | ask | show | jobs
by not-elite 1722 days ago
Wow, is it really this [1] easy to run a C routine?

Where does the rpi4 store the firmware necessary to read from the sd card where this software is (presumably) stored?

[1] https://github.com/isometimes/rpi4-osdev/blob/master/part1-b...

5 comments

There's a bootloader (u-boot) written into flash memory in the RPi4 SoC that handles the early initialization of the core and finding a kernel to boot. Think of u-boot as the UEFI equivalent for your RPi.

Getting into C (or Rust) assuming the presence of some kind of system firmware (BIOS, UEFI, u-boot, coreboot, etc.) isn't too difficult in the grand scheme of things.

Not to toot my own horn much, but here's an example I did of getting into Rust on a 386EX SBC i had hanging around. I actually yanked out the BIOS chip and this replaces it. Please forgive any poor Rust practices, this was written in a hurry.

https://github.com/teknoman117/ts-3100-images/tree/master/ru...

I discovered a mind-melting bug where replacing the RTC clock chip / battery-backed RAM can erase the BIOS. This SBC uses the same flash chip for both user storage and the BIOS. The partition between the user area and the bios is stored in the CMOS ram, so if there is any junk in it, the BIOS might misidentify the flash boundaries and erase itself...

So, I wrote this to recover the boards. Bonus points were that I only had an 8 KiB EEPROM hanging around so it had to fit in 8K initially.

It isn't u-boot, it's something totally barebones.
I forgot the RPi didn't use u-boot, but they use an equivalent.

https://github.com/isometimes/rpi4-osdev/tree/master/part2-b...

https://raspberrypi.stackexchange.com/questions/10489/how-do...

You don't handle the CPU from the reset vector like you would in a microcontroller or system firmware environment. There is an entire loader stack that finds a boot device to read a kernel image from that exists under you.

That's not to take away from this series at all, it's just the parent comment was asking about how it was so easy to get into a kernel image written in C on an SD card without any apparent SD card or FS logic.

> Where does the rpi4 store the firmware necessary to read from the sd card where this software is (presumably) stored?

The main chip of the RPi4 has a small amount of code in a built-in ROM which runs on boot. In the normal boot flow, that code loads the bootloader from the EEPROM chip, but it can also read a recovery image from the SD card. See https://www.raspberrypi.com/documentation/computers/raspberr... for details (or https://www.raspberrypi.com/documentation/computers/raspberr... for how it was on the older RPi devices).

Yeah, C is really easy to interface with assembly language.

The hard part is the linker-script to get this working right :-) https://github.com/isometimes/rpi4-osdev/blob/master/part1-b...

Yeah, C is really easy to interface with assembly language.

Doesn't necessarily have to involve assembly!

https://duckduckgo.com/?q=c+interpreter

The main core gets bootstrapped by the opaque binary blob in the graphics subsystem.
Yeah, the bootloader is responsible for the hardware stuff up to this point. It doesn't take that much more assembly code to bootstrap C in the Linux kernel on x86: https://github.com/torvalds/linux/blob/master/arch/x86/boot/...

There are a bunch of other headers in that file, but the "start_of_setup:" label is what's invoked by the bootloader, and "calll main" transitions to C. So 32 lines of code, by my count.