After what seems like most of the day spent chasing documentation around and around and trying all manner of ways to do a simple memory map I'm totally bewildered. So here I am.
What I want to do is map a 32 bit Raspberry Pi SoC register to users space, the system timer, and see it move.
I finally ended up with this code that does at least build and run:
use std::fs;
extern crate memmap;
use memmap::{MmapOptions};
pub fn map_system_timer() {
// All peripherals can be described by an offset from the Peripheral Base Address, which starts at:
// 0x20000000 on the Raspberry Pi model 1
// 0x3F000000 on the models 2 and 3.
const PERIPHERAL_BASE_ADDRESS: u64 = 0x3F000000;
// The System Timer is a hardware clock that can be used to keep time and generate interrupts after a certain time.
// It is located at offset 0x3000 from the peripheral base.
const SYSTEM_TIMER_OFFSET: u64 = 0x3000;
let f = fs::OpenOptions::new().read(true)
.write(true)
.open("/dev/mem")
.unwrap();
// Create a new memory map builder.
let mmap = unsafe {
MmapOptions::new()
.offset(PERIPHERAL_BASE_ADDRESS + SYSTEM_TIMER_OFFSET + 4)
.len(4096)
.map_mut(&f)
.unwrap()
};
let bytes = mmap.get(0..4).unwrap();
loop {
println!("{:?}", bytes);
}
}
Problem is only one of the four bytes printed ever move. The system timer counts at 1MHz.
I made a version of this in C just to check I had the right address. So I hope that is correct.
If that were working as expected my next issue is how to access it as a 32 bit integer in one go?
I never read embedded rust book, but I suppose it contains note about ptr read_volatile.
And I suppose your problem in exactly this.
Compiler optimize your memory reading and in fact your program just read once from register.
Yes, volatile, sounds like exactly like the sort of thing I need.That and reading 4 bytes in a single read operation.
Sadly I'm too dumb to make it compile let alone work. The documentation is making no sense to me. I have been chasing this around in circles for hours...
I managed to get a volatile pointer to my memory mapped timer register and can new see the time advancing. With this at the end of the code I showed above:
let ptr = mmap.as_ptr();
let volatile_ptr = ptr as *mut Volatile<i32>;
let one_second = time::Duration::from_secs(1);
loop {
unsafe {
println!("{:?}", &*volatile_ptr.offset(1));
}
thread::sleep(one_second);
}
It required adding the Copy trait to my SystemTimer, which seems a bit against the grain as there is only ever one of those in a system.
It required dereferencing the pointer, (*system_timer), which is ugly and also seems a bit odd because using read_volatile() did not require a dereference.
Problem is that neither of these approach compiles as --release using the nightly, failing with a SEGV:
don't forget to use #[repr(C)] for the structure, otherwise the compiler is allowed to reorder fields, which could cause quite some havoc here !
another suggestion would be to have the individual fields be volatile, instead of the struct—right now, to access one field it will copy the entire structure (that's why the need for the Copy trait at that level)
for additional inspiration you could take a look at svd2rust output for RegisterBlock, for example for the e310x (it's fairly difficult to read, though)
it uses vcell::VolatileCell<u32> (crate vcell) for the individual registers fields to abstract the volatile accesses
I had started to wonder about the scope of the volatile I had there. Certainly don't want to be hitting all the registers all the time.
That e310x thing is interesting. Perhaps the ugliest code I have seen for ages. Well, it is the output of a code generator. Just now I'm in the mood to do things for myself, from the ground up, with the minimum of support from ready made crates. Just to get more familiar with the language and the compiler error messages
Anyway here is how my System Timer interface looks now:
pub struct SystemTimer {
mmap: MmapMut,
}
#[repr(C)]
struct Registers {
control_and_status: Volatile<u32>,
counter_low: Volatile<u32>,
counter_high: Volatile<u32>,
compare_0: Volatile<u32>,
compare_1: Volatile<u32>,
compare_2: Volatile<u32>,
compare_3: Volatile<u32>,
}
impl SystemTimer {
fn map_registers() -> MmapMut {
// All peripherals can be described by an offset from the Peripheral Base Address, which starts at:
// 0x20000000 on the Raspberry Pi model 1
// 0x3F000000 on the models 2 and 3.
const PERIPHERAL_BASE_ADDRESS: u64 = 0x3F000000;
// The System Timer is a hardware clock that can be used to keep time and generate interrupts after a certain time.
// It is located at offset 0x3000 from the peripheral base.
const SYSTEM_TIMER_OFFSET: u64 = 0x3000;
let f = fs::OpenOptions::new().read(true)
.write(true)
.open("/dev/mem")
.unwrap();
// Create a new memory map builder and build a map.
let mmap: MmapMut = unsafe {
MmapOptions::new()
.offset(PERIPHERAL_BASE_ADDRESS + SYSTEM_TIMER_OFFSET)
.len(4096)
.map_mut(&f)
.unwrap()
};
mmap
}
pub fn read_counter_low(&self) -> u32 {
unsafe {
let registers = self.mmap.as_ptr() as *const Registers;
(*registers).counter_low.read()
}
}
}
pub fn take_system_timer() -> SystemTimer {
let mmap = SystemTimer::map_registers();
SystemTimer {
mmap: mmap,
}
}
Next up is to make it a singleton as described for peripherals in the embedded Rust book.
I wonder how seeking and read/writing in /dev/mem like that actually works. My fist guess is that, as that is a file operation, whole file blocks are getting read/written at some point rather than hitting individual 32 bit registers. In general this does not sound like what we want for peripherals. Probably OK for just reading this timer though. Then there is the matter of accuracy, with memory mapping the latency in reading the timer is only a pointer indirection.
Anyway, this is all part a some experiments in another direction. By isolating a core from the Linux kernel so that it cannot schedule any processes there and by disabling any interrupts on that core, we basically have a bare-metal environment to run in. We have a means of doing high speed/real-time things with no kernel scheduling jitters. We can experiment with our own task scheduling and so on. To that end direct access to peripherals via memory mapping is the way to keep the kernel out of things.
And, well, I'm here to learn some Rust. This has been another great exercise, which again confirms to me that Rust is great for systems programming, it offers such a lot as a language whilst also matching the performance of C at that same task.
