Indan Zupancic
Indan Zupancic
I think this can be merged.
I would just add `seL4_SetTLSBase()`, that would be the most consistent and easiest solution. If the kernel is not using `TPIDRURO` for anything itself, it safe to give write access...
> > AFAIK aarch64 is non-standard too now. > > Can you elaborate? On AArch64, `libsel4runtime` uses `tpidr_el0` [1], which seems like it could be considered "standard" based on this...
Both failing runs failed with: > No log to check boot failure on. But otherwise all is well.
There is something buggy going on with the DTB creation, if you change the configuration, the DTB isn't recreated properly either I think (at least the resulting image crashes, hinting...
> Looking back at the issue I made, some of the things mentioned probably don't belong in the manual. I must admit I wrote the documentation before re-reading your wish...
> It's a bit early to review the PR (should have left it on draft). We should sort out the API in the RFC discussion first. The RFC is higher...
> Fair enough, the code actually has slightly more than the RFC proposes. We should update the RFC then, the API decisions need to be there. I'm happy to move...
> @Indanz, I'm about to make the changes for supporting higher level affinity bits. Here is what I'm considering for the cap definition. (this is the aarch32 definition. The same...
> I would reduce the fields to just the IRQ and the target core ID, where the latter is a concatenation of `Aff0`, `RS`, `Aff1`, `Aff2` and `Aff3` for GICv3...