RPi bare bones: What's RPi-specific and what's not?

Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
Post Reply
User avatar
Roman
Member
Member
Posts: 568
Joined: Thu Mar 27, 2014 3:57 am
Location: Moscow, Russia
Contact:

RPi bare bones: What's RPi-specific and what's not?

Post by Roman »

Greetings, everyone.

I'm tinkering with Rust as a kernel development language for Raspberry Pi. I want my project to be organized in a way where target-specific components all live in their specific directories (just like in, for example, Linux). Concretely, architecture-dependent code is in src/arches/$(ARCH) and board-specific is in src/arches/$(ARCH)/plat/$(PLAT) (e.g. src/arches/arm/plat/bcm283x is for Raspberry Pi).

Currently I'm porting the bare bones tutorial, but I'm not sure what is specific to Raspberry Pi and what's not. As I understand, the peripherals offset (0x20200000) is specific to the SoC. But is the GPIO offset (peripherals + 0x200000) specific to the SoC? What about other offsets and the uart_* functions?
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
- Alan Kay
Nable
Member
Member
Posts: 453
Joined: Tue Nov 08, 2011 11:35 am

Re: RPi bare bones: What's RPi-specific and what's not?

Post by Nable »

Almost all MMIO addresses are SoC specific. Some of them are specific to the core of the SoC (e.g. for cortex-m3). I recommend you to learn about device tree: http://elinux.org/Device_Tree, it helps one to separate board-specific configuration entries from driver code.
onlyonemac
Member
Member
Posts: 1146
Joined: Sat Mar 01, 2014 2:59 pm

Re: RPi bare bones: What's RPi-specific and what's not?

Post by onlyonemac »

You might want to separate "arm" into different types of "arm" because "arm" can mean a lot of different things. You don't want to leave it until the "platform" separation stage to distinguish between different types of "arm" because there are many incompatible platforms where "arm" means the same thing and you'll be repeating a lot of identical code for each platform if you do this (because that identical code can't be put as common code for the "arm" architecture because of how different kinds of "arm" can be incompatible).
When you start writing an OS you do the minimum possible to get the x86 processor in a usable state, then you try to get as far away from it as possible.

Syntax checkup:
Wrong: OS's, IRQ's, zero'ing
Right: OSes, IRQs, zeroing
Post Reply