tock / libtock-rs

Rust userland library for Tock

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Can not get "console" example running on OpenTitan (CW310)

L0g4n opened this issue · comments

I was trying to get one of the examples up and running on the CW310 FPGA implementing the opentitan MCU.
Basically I'm not seeing any output from the userspace app (only from tockos binary).

My workflow consists of:

  1. Building the TockOS binary with the provided Makefile
  2. Building the console example with make opentitan EXAMPLE=console and using the generated tbf file with the TockOS provided flash-app target which combines everything in a single ELF and then converting it into a binary which is used to program the board in the end.

I am guessing my problem is that I need to manually adjust the SRAM address as mentioned in this repo's layout file. Can somebody give me any pointers what exactly I need to do with build tockos binary to adjust the memory origin?

BTW: The TBF_HEADER_SIZE was increased to 0x60 from 0x48, however, when I inspect the tbf file with tockloader it still says the TBF header has a size of 0x48. Is this a problem?

Do you see any error messages output by the kernel? If the issue is the app's flash location, you should see a diagnostic (either from the kernel or from the app); if the issue is the SRAM address then you should see a process fault message.

You will probably want to enable process loading debugging, set this to true and try again: https://github.com/tock/tock/blob/master/kernel/src/config.rs#L88

@alistair23 Damn, now I feel kinda stupid and wish I had known sooner of this feature.
Compiling with this feature lead to me to diagnose that 0x10004AFC is the first usable SRAM address
grafik

Changed the SRAM origin to the aforementioned address, and boom, it worked 🎉
grafik

The question I am asking myself, is there any way to determine this address a priori, without having to execute the kernel?

You can figure it out from the elf file, but it isn't easy. Your best bet is just running the kernel. Generally they don't need to be updated often, so it should be pretty fixed once you have the correct address

I see. So the address depends on the specific kernel binary which means as the compilation is not deterministic I need to check again? Or does it only change when the kernel source code also changes?

Our builds are reproducible*, so the address should only change when the kernel source code changes.

* tock/tock#1666 tracks this, technically they are not reproducible if you change the machine you are building on, because Rust embeds a hash in the binary indicating the OS used to build it (i.e. linux vs. macos)

Thanks!