M-Labs
/
artiq-zynq
10
1
Fork 19
Code Issues 13 Pull Requests Releases Wiki Activity

zc706 satellite can't have boot file reloaded to SD #179

New Issue
Closed
opened 2022-04-02 07:29:49 +08:00 by ljstephenson · 8 comments
ljstephenson commented 2022-04-02 07:29:49 +08:00
Copy Link

It's not possible to rewrite a satellite zc706's SD card with a new boot file via artiq_coremgmt, since it doesn't have any networking up.

This isn't a pressing issue since we don't have immediate plans to use the zc706 as a satellite, but still a corner case. The hardware design makes it pretty infeasible to access the SD card once it's in place.

It's not possible to rewrite a satellite zc706's SD card with a new boot file via `artiq_coremgmt`, since it doesn't have any networking up. This isn't a pressing issue since we don't have immediate plans to use the zc706 as a satellite, but still a corner case. The hardware design makes it pretty infeasible to access the SD card once it's in place.
mwojcik commented 2022-04-13 17:21:29 +08:00
Owner
Copy Link

A loose thought - what if SZL, for few seconds on bootup, was waiting for netboot, then if nothing connected, would proceeded with boot from SD? And netboot protocol itself would have to be extended to support writing boot.bin, overwriting the current image. So a satellite could be updated by Ethernet on boot.

A loose thought - what if SZL, for few seconds on bootup, was waiting for netboot, then if nothing connected, would proceeded with boot from SD? And netboot protocol itself would have to be extended to support writing ``boot.bin``, overwriting the current image. So a satellite could be updated by Ethernet on boot.
sb10q commented 2022-04-13 17:25:09 +08:00
Owner
Copy Link

Satellites don't necessarily have Ethernet connected.

Satellites don't necessarily have Ethernet connected.
ljstephenson commented 2022-04-14 05:34:23 +08:00
Author
Copy Link

Reiterating that this very low on the priority list, but to summarise my thoughts and how I understand things (which may well be wrong):

  • Rewriting Kasli gateware remotely is easy via JTAG over USB.
  • Rewriting ZC706 gateware appears to need either some way of rewriting boot.bin or just always booting from JTAG, using a separate adapter since the on-board USB is unreliable.

Are we at NIST the only people using ZC706 as opposed to Kasli SoC? It wouldn't be unreasonable to require Ethernet connection for ZC706 satellites if this functionality is necessary.

From @mwojcik 's comment though it sounds like this could be a reasonable amount of work - I definitely don't need this for my experiment in the foreseeable future, just wanted to make sure it was noted as a potential pitfall in case there was an easy solution.

Reiterating that this very low on the priority list, but to summarise my thoughts and how I understand things (which may well be wrong): * Rewriting Kasli gateware remotely is easy via JTAG over USB. * Rewriting ZC706 gateware appears to need either some way of rewriting `boot.bin` or just always booting from JTAG, using a separate adapter since the on-board USB is unreliable. Are we at NIST the only people using ZC706 as opposed to Kasli SoC? It wouldn't be unreasonable to require Ethernet connection for ZC706 satellites if this functionality is necessary. From @mwojcik 's comment though it sounds like this could be a reasonable amount of work - I definitely don't need this for my experiment in the foreseeable future, just wanted to make sure it was noted as a potential pitfall in case there was an easy solution.
sb10q commented 2022-04-14 07:59:01 +08:00
Owner
Copy Link

Rewriting ZC706 gateware appears to need either some way of rewriting boot.bin or just always booting from JTAG, using a separate adapter since the on-board USB is unreliable.

If you put only SZL into boot.bin, then it will get the bitstream and runtime from the network.

Accessing satellite config and flashing through DRTIO would be nice to have in ARTIQ generally though.

> Rewriting ZC706 gateware appears to need either some way of rewriting boot.bin or just always booting from JTAG, using a separate adapter since the on-board USB is unreliable. If you put only SZL into ``boot.bin``, then it will get the bitstream and runtime from the network. Accessing satellite config and flashing through DRTIO would be nice to have in ARTIQ generally though.
👍 1
ljstephenson commented 2022-04-14 09:25:47 +08:00
Author
Copy Link

Is setting up a netboot server reasonably simple? How does this differentiate if you have e.g. both a master and satellite using netboot?

Agreed that being able to do it via DRTIO seems very nice to have, and a clean solution.

Is setting up a netboot server reasonably simple? How does this differentiate if you have e.g. both a master and satellite using netboot? Agreed that being able to do it via DRTIO seems very nice to have, and a clean solution.
mwojcik commented 2022-04-14 10:16:50 +08:00
Owner
Copy Link

Technically the server is inside SZL (the bootloader of zc706/KasliSoC). Then you only need the client: https://git.m-labs.hk/m-labs/artiq-netboot

As for differentiating devices, that could be done by IP - changing the config (with artiq_coremgt or editing config file on SD card) will also change the IP address of SZL's netboot. So you could have the master at (for example) 192.168.1.56 and the satellite at 192.168.1.57 - and the address would be used only for loading firmware, nothing else.

Technically the server is inside SZL (the bootloader of zc706/KasliSoC). Then you only need the client: https://git.m-labs.hk/m-labs/artiq-netboot As for differentiating devices, that could be done by IP - changing the config (with ``artiq_coremgt`` or editing config file on SD card) will also change the IP address of SZL's netboot. So you could have the master at (for example) ``192.168.1.56`` and the satellite at ``192.168.1.57`` - and the address would be used only for loading firmware, nothing else.
ljstephenson commented 2022-04-15 23:38:49 +08:00
Author
Copy Link

Oh I see - I was under the impression that the coredevice would try to fetch its bitstream from a server, rather than providing a server that waits until a client supplies the bitstream. Makes sense!

Oh I see - I was under the impression that the coredevice would try to fetch its bitstream from a server, rather than providing a server that waits until a client supplies the bitstream. Makes sense!
esavkin was assigned by sb10q 2022-10-21 18:43:26 +08:00
mwojcik commented 2024-11-20 08:51:50 +08:00
Owner
Copy Link

Finally possible with #323.

Finally possible with #323.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
master
release-7
release-8
release-6
Labels
Clear labels   
priority:critical

   
priority:high

   
priority:low

   
priority:medium
No Label
priority:critical
priority:high
priority:low
priority:medium
Milestone
Clear milestone
No items
No Milestone
Assignees
Clear assignees
No Assignees
esavkin
3 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/artiq-zynq#179
No description provided.
Delete Branch "%!s(<nil>)"

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?