netboot #100
No reviewers
Labels
No Milestone
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: M-Labs/artiq-zynq#100
Loading…
Reference in New Issue
No description provided.
Delete Branch "pca006132/artiq-zynq:netboot"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Implemented #96.
@ -32,8 +32,10 @@ let
installPhase = ''
mkdir -p $out $out/nix-support
cp ../build/firmware.bin $out/firmware.bin
Call it runtime.bin for consistency.
@ -16,2 +17,4 @@
while core0_tx.is_none() {
core0_tx = CHANNEL_0TO1.lock().take();
// prevent deadlock...
// the compiler optimized this routine so fast that it would deadlock
Wait, why?
I think the possible reason is due to the load-store exclusive used by the processor. The load-store exclusive would monitor for the cache line, and the store would fail if the cache lines was written.
Consider the following sequence:
With this sequence, core1 would be starved to death without every modifying the content of the mutex. Core0 would keep repeating the sequence as core1 haven't put the channels in the mutex.
Just my guess, not sure if this is what really happening in the hardware.
@ -50,3 +50,3 @@
{
__heap0_start = .;
. += 0x800000;
. += 0x8000000;
Please move into separate commit.
@ -96,0 +57,4 @@
ram::init_alloc_core0();
match slcr::RegisterBlock::unlocked(|slcr| slcr.boot_mode.read().boot_mode_pins()) {
slcr::BootModePins::Jtag => netboot::netboot(ddr.ptr()),
Maybe define a section in the linker script for the executable. Then both the start address and the maximum length can be obtained from there.
@ -96,0 +73,4 @@
let runtime = cfg
.read("runtime")
.expect("Expected runtime in SD card for SD card boot mode");
assert!(runtime.len() < 0x800000, "runtime binary too large");
I suggest not crashing on those errors, but going into netboot mode.
@ -97,0 +82,4 @@
}
};
info!("Preparing for runtime execution!");
nitpick: remove the exclamation mark
Merging before this is done will break the tests, so let's merge all the relevant PRs at the same time.
@ -25,2 +28,3 @@
fi
openocd -f zc706.cfg -c "$load_bitstream_cmd load_image ../build/firmware/armv7-none-eabihf/release/szl; resume 0; exit"
openocd -f zc706.cfg -c "load_image ../build/firmware/armv7-none-eabihf/debug/szl; resume 0; exit"
artiq_netboot $load_bitstream_cmd -f ../build/runtime.bin -b $board_host
No delay?
@ -18,0 +20,4 @@
// the compiler optimized this routine so fast that it would deadlock
for _ in 0..100 {
nop();
}
Please remove from the netboot PR, as well as optimizations. Let's do one thing at a time. Also this is a tricky issue that needs proper consideration, this
nop
fix isn't looking good.@ -29,0 +35,4 @@
if (slot as usize) < (&__stack1_end as *const u32 as usize) {
panic!("Core1 stack overflow")
}
}
also split into separate PR
@ -0,0 +141,4 @@
) -> Result<(), PlLoadingError> {
let size = locate_bitstream(file)?;
unsafe {
// align to 64 bytes
This wasn't done before?
yes, I just found that the alignment is required.
perhaps the allocator would have some alignment by the smallest block size or something.
@ -75,0 +76,4 @@
}
};
info!("Loading gateware!");
remove exclamation mark
@ -75,0 +72,4 @@
let cfg = match Config::new() {
Ok(cfg) => cfg,
Err(_) => {
panic!("No config for SZL");
Go to netboot there as well
@ -75,0 +80,4 @@
load_pl::load_bitstream_from_sd().unwrap();
info!("Loading runtime");
let runtime = cfg.read("runtime");
Why not use the same format as FSBL? We're already doing that for the bitstream. And FSBL compatibility is nice to have in practice, as #94 shows.
closing to split into multiple PRs.
@ -48,4 +44,2 @@
mod irq;
fn init_gateware() {
// Set up PS->PL clocks
This must stay
Pull request closed