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

figure out way to reset Core1 from SDRAM #24

New Issue
Closed
opened 2020-04-27 13:51:28 +08:00 by sb10q · 4 comments
sb10q commented 2020-04-27 13:51:28 +08:00
Owner

Eventually we want to run everything from the SDRAM. I have some dirty proof-of-concept code that does that, but I'm having trouble with Core1 resets, which seem to always go to the OCM regardless of the VBAR value.

Is there a way to remap the reset vector that would persist when Core0 resets Core1? If not, maybe instead of a reset we should use a IRQ or similar?

Current implementation is a hack where the first-stage OCM code stays, and jumps to the SDRAM when executed by Core1.

Eventually we want to run everything from the SDRAM. I have some dirty proof-of-concept code that does that, but I'm having trouble with Core1 resets, which seem to always go to the OCM regardless of the VBAR value. Is there a way to remap the reset vector that would persist when Core0 resets Core1? If not, maybe instead of a reset we should use a IRQ or similar? Current implementation is a hack where the first-stage OCM code stays, and jumps to the SDRAM when executed by Core1.
sb10q commented 2020-05-06 18:15:14 +08:00
Poster
Owner

It seems Core1 will always execute from OCM after a reset.

Maybe the simplest reliable solution is for the runtime to write a "branch to DDR" instruction at the beginning of OCM.

It seems Core1 will always execute from OCM after a reset. Maybe the simplest reliable solution is for the runtime to write a "branch to DDR" instruction at the beginning of OCM.
sb10q commented 2020-05-06 22:17:59 +08:00
Poster
Owner

4e1f46b3e2

Doesn't seem like there's a better way. Other people do very complicated things like this: https://www.osti.gov/servlets/purl/1499223

https://git.m-labs.hk/M-Labs/zc706/commit/4e1f46b3e232609b7bc8d818f60ce07fa769d93b Doesn't seem like there's a better way. Other people do very complicated things like this: https://www.osti.gov/servlets/purl/1499223
sb10q closed this issue 2020-05-06 22:18:04 +08:00
sb10q commented 2020-05-06 22:32:52 +08:00
Poster
Owner

Okay that didn't work very well, now kernels crash with "PrefetchAbort"...

[     0.000000s]  INFO(szl): Simple Zynq Loader starting...
[     0.005394s] DEBUG(libboard_zynq::clocks::source): Set ARM_PLL to 1600000000 Hz
[     0.010573s] DEBUG(libboard_zynq::clocks::source): Set IO_PLL to 1000000000 Hz
[     0.017798s] DEBUG(libboard_zynq::clocks::source): Set DDR_PLL to 1333333332 Hz
[     0.025263s] DEBUG(libboard_zynq::ddr): DDR 3x/2x clocks: 666666660/444444440
[     0.032381s] DEBUG(libboard_zynq::ddr): DDR DCI clock: 10582010 Hz
[     0.041343s]  INFO(szl): decompressing payload
[     0.089682s]  INFO(szl): executing payload
[     0.000003s]  INFO(runtime): NAR3 starting...
[     0.004609s]  INFO(runtime): gateware already loaded
[     0.009568s]  INFO(runtime): detected gateware: RTIO_ZC706
[     0.018071s] DEBUG(runtime::kernel): Core1 started
[     3.580562s]  INFO(libboard_zynq::eth): eth: got Link { speed: S1000, duplex: Half }
[  1211.656298s] DEBUG(runtime::comms): received connection
[  1211.670698s] DEBUG(runtime::kernel): Core1 started
[  1211.675776s]  INFO(dyld): ELF target: 12324 bytes, align to 1000, allocated at 0013D000
[  1211.683957s]  INFO(dyld): Relocating 0 rela, 0 rel, 0 pltrel
[  1211.689646s] DEBUG(runtime::kernel): kernel loaded
[  1211.695116s] DEBUG(runtime::kernel): kernel starting
PrefetchAbort
[  1268.344028s] DEBUG(runtime::comms): received connection
[  1268.358472s] DEBUG(runtime::kernel): Core1 started
[  1268.363561s]  INFO(dyld): ELF target: 12324 bytes, align to 1000, allocated at 0013D000
[  1268.371747s]  INFO(dyld): Relocating 0 rela, 0 rel, 0 pltrel
[  1268.377435s] DEBUG(runtime::kernel): kernel loaded
[  1268.382891s] DEBUG(runtime::kernel): kernel starting
PrefetchAbort

Note: kernels were already broken in the preceding commit

[     0.000003s]  INFO(runtime): NAR3 starting...
[     0.004634s]  INFO(runtime): Detected gateware: RTIO_ZC706
[     0.013303s] DEBUG(runtime::kernel): Core1 started

[     3.529618s]  INFO(libboard_zynq::eth): eth: got Link { speed: S1000, duplex: Half }
[     7.104899s] DEBUG(runtime::comms): received connection
[     7.119227s] DEBUG(runtime::kernel): Core1 started
[     7.124305s]  INFO(dyld): ELF target: 12324 bytes, align to 1000, allocated at 0013D000
[     7.132490s]  INFO(dyld): Relocating 0 rela, 0 rel, 0 pltrel
[     7.138177s] DEBUG(runtime::kernel): kernel loaded
[     7.143669s] DEBUG(runtime::kernel): kernel starting
panic at /nix/store/702z0r414f4yb30pip0cf7p9pm5mfsyh-rust-94d3463/src/libcore/fmt/num.rs:84:20: slice index starts at 469 but ends at 128
Okay that didn't work very well, now kernels crash with "PrefetchAbort"... ```text [ 0.000000s] INFO(szl): Simple Zynq Loader starting... [ 0.005394s] DEBUG(libboard_zynq::clocks::source): Set ARM_PLL to 1600000000 Hz [ 0.010573s] DEBUG(libboard_zynq::clocks::source): Set IO_PLL to 1000000000 Hz [ 0.017798s] DEBUG(libboard_zynq::clocks::source): Set DDR_PLL to 1333333332 Hz [ 0.025263s] DEBUG(libboard_zynq::ddr): DDR 3x/2x clocks: 666666660/444444440 [ 0.032381s] DEBUG(libboard_zynq::ddr): DDR DCI clock: 10582010 Hz [ 0.041343s] INFO(szl): decompressing payload [ 0.089682s] INFO(szl): executing payload [ 0.000003s] INFO(runtime): NAR3 starting... [ 0.004609s] INFO(runtime): gateware already loaded [ 0.009568s] INFO(runtime): detected gateware: RTIO_ZC706 [ 0.018071s] DEBUG(runtime::kernel): Core1 started [ 3.580562s] INFO(libboard_zynq::eth): eth: got Link { speed: S1000, duplex: Half } [ 1211.656298s] DEBUG(runtime::comms): received connection [ 1211.670698s] DEBUG(runtime::kernel): Core1 started [ 1211.675776s] INFO(dyld): ELF target: 12324 bytes, align to 1000, allocated at 0013D000 [ 1211.683957s] INFO(dyld): Relocating 0 rela, 0 rel, 0 pltrel [ 1211.689646s] DEBUG(runtime::kernel): kernel loaded [ 1211.695116s] DEBUG(runtime::kernel): kernel starting PrefetchAbort [ 1268.344028s] DEBUG(runtime::comms): received connection [ 1268.358472s] DEBUG(runtime::kernel): Core1 started [ 1268.363561s] INFO(dyld): ELF target: 12324 bytes, align to 1000, allocated at 0013D000 [ 1268.371747s] INFO(dyld): Relocating 0 rela, 0 rel, 0 pltrel [ 1268.377435s] DEBUG(runtime::kernel): kernel loaded [ 1268.382891s] DEBUG(runtime::kernel): kernel starting PrefetchAbort ``` Note: kernels were already broken in the preceding commit ```text [ 0.000003s] INFO(runtime): NAR3 starting... [ 0.004634s] INFO(runtime): Detected gateware: RTIO_ZC706 [ 0.013303s] DEBUG(runtime::kernel): Core1 started [ 3.529618s] INFO(libboard_zynq::eth): eth: got Link { speed: S1000, duplex: Half } [ 7.104899s] DEBUG(runtime::comms): received connection [ 7.119227s] DEBUG(runtime::kernel): Core1 started [ 7.124305s] INFO(dyld): ELF target: 12324 bytes, align to 1000, allocated at 0013D000 [ 7.132490s] INFO(dyld): Relocating 0 rela, 0 rel, 0 pltrel [ 7.138177s] DEBUG(runtime::kernel): kernel loaded [ 7.143669s] DEBUG(runtime::kernel): kernel starting panic at /nix/store/702z0r414f4yb30pip0cf7p9pm5mfsyh-rust-94d3463/src/libcore/fmt/num.rs:84:20: slice index starts at 469 but ends at 128 ```
sb10q reopened this issue 2020-05-06 22:32:55 +08:00
sb10q commented 2020-05-07 10:46:11 +08:00
Poster
Owner

Unrelated libdyld bug fixed in d08f4552ab

Unrelated libdyld bug fixed in https://git.m-labs.hk/M-Labs/artiq-zynq/commit/d08f4552abdf7581cd4bdc73b636f6d5207b3621
sb10q closed this issue 2020-05-07 10:46: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
1 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#24
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?