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

Open
opened 2022-04-02 07:29:49 +08:00 by ljstephenson · 7 comments

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.

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.

Satellites don't necessarily have Ethernet connected.

Satellites don't necessarily have Ethernet connected.

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.

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.

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.

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.

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
Sign in to join this conversation.
No Milestone
No Assignees
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
There is no content yet.