Skip to content

nrf51: convert crt1.c to rust (UNTESTED - NOMERGE) #369

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
wants to merge 8 commits into from
Closed

nrf51: convert crt1.c to rust (UNTESTED - NOMERGE) #369

wants to merge 8 commits into from

Conversation

@ppannuto
Copy link
Member

@ppannuto ppannuto commented May 4, 2017

Starting to get down a rabbit hole here:

So, #367 is blocked because it doesn't build on the NRF. This is because the build.rs gcc invocation is emitting a .got section that being pulled into the vector_table, which overruns its now limited size (before it was just wasted/ignored space). Of the two paths forward (1) fixing the C compilation or (2) porting the nrf crt1.c to Rust, @brghena pushed me to the latter, which was the right choice.

Thus this PR, which is now blocked because it manages to trip a known bug ( https://bugs.llvm.org//show_bug.cgi?id=30279 found via japaric/f3#42 ) in LLVM 3.9, which our current nightly is at. Thus, we need to bump nightlies to get to LLVM 4.0, which will be the next PR, forthcoming either later tonight or tomorrow depending on how easy/hard the nightly bump is.

@ppannuto ppannuto added blocked Waiting on something, like a different PR or a dependency. kernel chips/nrf Change pertains to the nRF5x family of MCUs. labels May 4, 2017
@alevy
Copy link
Member

alevy commented May 4, 2017

@niklasad1 @frenicth would be great if you could take a look at this too.

@alevy
Copy link
Member

alevy commented May 4, 2017

We definitely want to port to Rust. If this proves challanging, I'll take it on as part of another change i want to make w.r.t interrupt handling anyway.

@alevy alevy mentioned this pull request May 24, 2017
Closed
@ppannuto ppannuto mentioned this pull request May 26, 2017
Merged
@ppannuto
Copy link
Member Author

Current status:

panic's pretty immediately:

(gdb) c
Continuing.
^C
Program received signal SIGTRAP, Trace/breakpoint trap.
0x000026ce in rust_begin_unwind ()
(gdb) bt
#0  0x000026ce in rust_begin_unwind ()
#1  0x0000718c in core::panicking::panic_fmt::h751dd6319a45ae56 ()
#2  0x00005b42 in nrf51::unhandled_interrupt::h2966b4618ae92f65 ()
#3  0x00005b42 in nrf51::unhandled_interrupt::h2966b4618ae92f65 ()
......

tossing in a breakpoint a few instructions into unhandled_interrupt so we can catch the ipsr while it's in r0: r0 0x12 18 (or just read xpsr, duh pat xpsr 0x1000012 16777234), we're in theory in ISR number 18, but that doesn't totally jive hex(18*4) = 0x48, and:

00000000 <BASE_VECTORS>:
       0:	1ad8      	subs	r0, r3, r3
       2:	2000      	movs	r0, #0
       4:	281d      	cmp	r0, #29
       6:	0000      	movs	r0, r0
       8:	5b0d      	ldrh	r5, [r1, r4]
       a:	0000      	movs	r0, r0
       c:	5b0d      	ldrh	r5, [r1, r4]
       e:	0000      	movs	r0, r0
      10:	5b0d      	ldrh	r5, [r1, r4]
      12:	0000      	movs	r0, r0
      14:	5b0d      	ldrh	r5, [r1, r4]
      16:	0000      	movs	r0, r0
      18:	5b0d      	ldrh	r5, [r1, r4]
      1a:	0000      	movs	r0, r0
      1c:	5b0d      	ldrh	r5, [r1, r4]
      1e:	0000      	movs	r0, r0
      20:	5b0d      	ldrh	r5, [r1, r4]
      22:	0000      	movs	r0, r0
      24:	5b0d      	ldrh	r5, [r1, r4]
      26:	0000      	movs	r0, r0
      28:	5b0d      	ldrh	r5, [r1, r4]
      2a:	0000      	movs	r0, r0
      2c:	5d91      	ldrb	r1, [r2, r6]
      2e:	0000      	movs	r0, r0
      30:	5b0d      	ldrh	r5, [r1, r4]
      32:	0000      	movs	r0, r0
      34:	5b0d      	ldrh	r5, [r1, r4]
      36:	0000      	movs	r0, r0
      38:	5b0d      	ldrh	r5, [r1, r4]
      3a:	0000      	movs	r0, r0
      3c:	5d41      	ldrb	r1, [r0, r5]
	...

00000040 <IRQS>:
      40:	5dc1      	ldrb	r1, [r0, r7]
      42:	0000      	movs	r0, r0
      44:	5dc1      	ldrb	r1, [r0, r7]
      46:	0000      	movs	r0, r0
      48:	5dc1      	ldrb	r1, [r0, r7]

That should be in the generic_isrs part of the table, not the unhandled_interrupt - I'm misreading something that will hopefully be obvious with fresh eyes.

ohh... what if generic's jumping to unhandled somehow?

(gdb) break *0x00005dc0
Breakpoint 3 at 0x5dc0
(gdb) mon reset
Resetting target
(gdb) c
Continuing.

Breakpoint 1, 0x00002826 in reset_handler ()
(gdb) c
Continuing.

Breakpoint 3, 0x00005dc0 in generic_isr ()
(gdb) info registers
r0             0x20003ac1	536885953
r1             0x17	23
r2             0x0	0
r3             0x0	0
r4             0x20000a00	536873472
r5             0x20001ad8	536877784
r6             0x2014a	131402
r7             0x20003ac0	536885952
r8             0xffffffff	4294967295
r9             0xffffffff	4294967295
r10            0xffffffff	4294967295
r11            0xffffffff	4294967295
r12            0xffffffff	4294967295
sp             0x20001888	0x20001888
lr             0xfffffff9	4294967289
pc             0x5dc0	0x5dc0 <generic_isr>
xpsr           0x61000012	1627389970
msp            0x20001888	536877192
psp            0xfffffffc	4294967292
primask        0x0	0
basepri        0x0	0
faultmask      0x0	0
control        0x0	0
(gdb) s
Single stepping until exit from function generic_isr,
which has no line number information.
0x00005b0c in nrf51::unhandled_interrupt::h2966b4618ae92f65 ()
(gdb) info registers
r0             0x5b0d	23309
r1             0x8d64	36196
r2             0x0	0
r3             0x0	0
r4             0x20000a00	536873472
r5             0x20001ad8	536877784
r6             0x2014a	131402
r7             0x20003ac0	536885952
r8             0xffffffff	4294967295
r9             0xffffffff	4294967295
r10            0xffffffff	4294967295
r11            0xffffffff	4294967295
r12            0xffffffff	4294967295
sp             0x20001884	0x20001884
lr             0x5df7	24055
pc             0x5b0c	0x5b0c <nrf51::unhandled_interrupt::h2966b4618ae92f65>
xpsr           0x1000012	16777234
msp            0x20001884	536877188
psp            0xfffffffc	4294967292
primask        0x0	0
basepri        0x0	0
faultmask      0x0	0
control        0x0	0
(gdb)

yeah.. that's absolutely what's happening. It is not immediately obvious how generic isr ends up jumping to unhandled interrupt without triggering another interrupt though?

This stream-of-consciousness debug session to be picked up again tomorrow

@ppannuto
Copy link
Member Author

Oh yeah.. generic_isr will be interleaving here - following this path, it's not a process interrupt, so jump to no stacking, from ipsr we're looking for interrupt 0x12, which is entry 0x12-16 = 2 in our interrupt table which is /* UART0_Handler */ Option::Some(unhandled_interrupt), which totally jives because that probably just finished writing and that interrupt needs to go somewhere useful - great

@ppannuto
Copy link
Member Author

Okay, that hack just results in a hard fault. Actually stopping working on this for the day now.

@alevy alevy mentioned this pull request Jun 6, 2017
Merged
@bradjc bradjc modified the milestone: Tock 1.0 Jun 22, 2017
@alevy alevy modified the milestones: Post Tock 1.0, Tock 1.0 Aug 3, 2017
@ppannuto ppannuto mentioned this pull request Oct 12, 2017
Merged
3 tasks
ppannuto added a commit that referenced this pull request Oct 17, 2017
@ppannuto
nrf5x: corrode crt1.c -> crt1.rs
c6c58c2 
Using https://github.com/jameysharp/corrode, automatically convert the
old crt1.c to Rust. In contrast to #369, which sought to update this
file to newer Tock conventions, this is a blind translation, but should
hopefully unblock #367.
@niklasad1
Copy link
Member

@ppannuto close this now when #649 is merged?

@ppannuto
Copy link
Member Author

Yeah, I think there is still some work to be done to convert #649 to more human-friendly Rust, but that’s a different path forward than this PR.

@ppannuto ppannuto closed this Oct 18, 2017
@bradjc bradjc deleted the no-more-c branch December 7, 2017 18:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

blocked Waiting on something, like a different PR or a dependency. chips/nrf Change pertains to the nRF5x family of MCUs. kernel needs-squash

Projects

None yet

Milestone

Post Tock 1.0

Development

Successfully merging this pull request may close these issues.

5 participants

@ppannuto @alevy @niklasad1 @bradjc