Temporary Update Firmware via Ethernet

Hi skorson ,

Unfortunately some of the colleagues that would know to give a more definitive answer are out of office due to holidays, as such it might take a few days until someone settles this issue.

Until then, these are my findings:
- pluto_ramboot script calls device_reboot which in turn writes 7 to /sys/kernel/debug/zynq_rst/code
- The sysfs attribute writes to the kernel variable zynq_rst_code. The value is used when a reboot is triggered here: reboot |= zynq_rst_code; 
- Then this value is written to the register  "SLCR_REBOOT_STATUS_OFFSET 0x258 /* PS Reboot Status */"

From here I have gotten kind of stuck, and could not progress either with the commit message that introduced the sysfs attribute: "This option adds an extra DBFS entry debug/zynq_rst/code. Values written are passed via REG slcr.REBOOT_STATUS Bits 15:0." nor the zynq documentation of this register field: BOOTROM_ERROR_CODE.

At this time my assumption is that those values are used after the soft reboot by the FSBL, so at minimum your request would require modifications to the FSBL but I could be wrong.


Dumitru

Values passed through this resister are persistent during soft reset.

Some u-boot scripts will read the reset cause and act accordingly.

https://github.com/analogdevicesinc/u-boot-xlnx/commit/74805f69632181d8e73e6bf7308d42cdee926712

-Michael

Thank you kindly for your response. I apologize for the delay but I have been sidetracked by yet more issues. I don't fully understand the details, but you have given me a place to look. Sadly I expect it will be more complicated than "Put file in this location for a non-flashed reboot, or put it here to be flashed then reboot." :-P

Edit: What would be good to know is the differences (which seem very non-trivial) between the DFU reboot with or without flashing (pluto_ramboot) vs. the on-device update_frm.sh process. They seem quite different. Anyway to use the DFU modes via ethernet? Thx!

Thank you. This is more information for digging.

From digging a little more I would say that the simplest approach to obtain ramboot only with OTG-Ethernet would be either "tftp booting" or "dfu tftp" directly from u-boot but it would require for you to also be connected to the UART port.

From the u-boot terminal I can see that OTG works from u-boot as well and detects the adapter:

M2k> usb start
starting USB...
USB0:   USB EHCI 1.00
scanning bus 0 for devices... 2 USB Device(s) found
USB1:   usb1 wrong num MIO: 0, Index 1
lowlevel init failed
       scanning usb for storage devices... 0 Storage Device(s) found
M2k> usb tree
USB device tree:
  1  Hub (480 Mb/s, 0mA)
  |  u-boot EHCI Host Controller 
  |
  +-2  Vendor specific (480 Mb/s, 350mA)
       Realtek USB 10/100/1000 LAN 001000001

Thank you dumitruCeclan Dumitru for the details. Yes, I do have a JTAG debugger and full Xilinx kit. Also, I understand that this is getting outside the realm of support from here out. I am very much appreciative of your feedback. I will experiment with this and report back.