M-Labs
/
zynq-rs
10
0
Fork 12
Code Issues 6 Pull Requests 1 Releases Wiki Activity

Naked function must contain a single asm block #73

New Issue
Closed
opened 2021-01-14 16:40:17 +08:00 by pca006132 · 4 comments
pca006132 commented 2021-01-14 16:40:17 +08:00

https://github.com/rust-lang/rust/issues/32408

Warning on latest nightly, would become hard error later.
But I'm not sure how should we run other functions from interrupt with asm block only, maybe we should mark the functions as extern "C" and call them from asm?

https://github.com/rust-lang/rust/issues/32408 Warning on latest nightly, would become hard error later. But I'm not sure how should we run other functions from interrupt with asm block only, maybe we should mark the functions as `extern "C"` and call them from asm?
astro commented 2021-01-14 23:24:45 +08:00

maybe we should mark the functions as extern "C" and call them from asm?

That seems to be the way forward.

Perhaps we can create a shared abstraction (macro_rules) that works with our memory model for all our naked fns.

> maybe we should mark the functions as extern "C" and call them from asm? That seems to be the way forward. Perhaps we can create a shared abstraction (macro_rules) that works with our memory model for all our naked fns.
pca006132 commented 2021-01-15 14:10:43 +08:00
Poster

It seems that the new compiler also break our code regarding core1.

The experiments break even if changes to the memcpy is removed, and only works when I comment out boot::Core1::start(false); and related core1 code.

Not sure what is happening here.

My fork with updated compiler: https://git.m-labs.hk/pca006132/zynq-rs

It seems that the new compiler also break our code regarding core1. The experiments break even if changes to the `memcpy` is removed, and only works when I comment out `boot::Core1::start(false);` and related core1 code. Not sure what is happening here. My fork with updated compiler: https://git.m-labs.hk/pca006132/zynq-rs
sb10q closed this issue 2021-01-15 17:40:02 +08:00
pca006132 commented 2021-01-18 09:54:48 +08:00
Poster

Using extern "C" function instead of naked function would break kernel code. Getting weird interrupts after several restarts.

Reopening to see if there is any better solution.

I'm not sure using a naked function to call an extern "C" function by bl ... could work. (It does not work)

Using `extern "C"` function instead of naked function would break kernel code. Getting weird interrupts after several restarts. Reopening to see if there is any better solution. ~~I'm not sure using a naked function to call an `extern "C"` function by `bl ...` could work.~~ (It does not work)
pca006132 commented 2021-01-18 17:00:20 +08:00
Poster

Maybe we should initialize SP for other interrupt handlers as well. idk why it works now, considering the SP should point to 0 and idk how the registers are pushed to the stack...

Maybe we should initialize `SP` for other interrupt handlers as well. idk why it works now, considering the `SP` should point to 0 and idk how the registers are pushed to the stack...
sb10q closed this issue 2021-01-28 12:34:14 +08:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
master
esavkin/reboot_support
Labels
Clear labels
No items
No Label
Milestone
Clear milestone
No items
No Milestone
Assignees
Clear assignees
No Assignees
2 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: M-Labs/zynq-rs#73
There is no content yet.
Delete Branch "%!s(<nil>)"

Deleting a branch is permanent. Although the deleted branch may exist for a short time before cleaning up, in most cases it CANNOT be undone. Continue?