Manually updating xilinx zynq firmware with contents of swupdate package

[Postal2]

I can also pile on a lot.

Code: [Select]

ECC Data Bytepos=32a Bitpos=40 correctedC.ifr_newnewx.so.ifr_new:583 CRC error 
ECC Data Bytepos=1c Bitpos=4 corrected   5 10005    14 vmAC.ifr_newcrc32 for
DDR  DPLL in Lock mode:ifr_05    14 Mod
Jan 01
  DDR  clock 266 Mhz [266/1]4 touchdriver.ifr_new5    5
Disp DPLL in Lock mode:fr_
Jan 01 00:00:00.339
  Disp clock 192 Mhz [192/1]0005    14 spidriver.ifr_new
MPU  DPLL in Lock mode:ver.ifr_new00.338    5
  MPU  clock 800 Mhz [800/1]  5 10005    14 resources.if
PER  DPLL in Lock mode:14 Progress 100n 01 00:
  PER  clock 192 Mhz [960/5]336    5 10005    14 md4_tim
CORE DPLL in Lock mode:ROR: Ifr file md4_qnx_d
  M4 CORE clock 200 Mhz [2000/10]7    5 10005    14 md4_qt.ifr_new
  M5 CORE clock 250 Mhz [2000/8]2 error
Jan 01
EC
Jan 01 00:00:
  M6 CORE clock 500 Mhz [2000/4]fr_new    14 touchdriver.ifr_
E

Jumping to QNXs=be2 Bitpo
Ja
MD4 QNX startup7    5 10005   
nanddriver: devio_readtrans:583 CRC errorpos=80 correctedewogress 100       
Jan 0
Time                 Sev Major 32a Bit                     
Jan 01 00:00:00.337    5 10005    14 vmGC.ifr_newnewio_readtrans:583 CRC error.R  DPLL in Lock mod
Jan 01 00:00:00.337    5 10005    14 vmAC.ifr_newcrc32 for module md4_qnx_display.ifr_05    14 Mod
Jan 01 00:00:00.337    5 10005    14 touchdriver.ifr_new# ECC Data
new started0:00.335   
Jan 01 00:00:00.340 
Jan 01 00:00:00.337    5 10005    14 spidriver.ifr_new invorrected14 libmd4
Jan 01 00:00:00.335    5 10005 
Jan 01 00:00:00.338    5 10005    14 resources.ifr_new.429    5 10005    14 Progress 100n 01 00:00:00.335   
Jan 01 00:00:00.338    5 10005    14 md4_time.ifr_new 10005    14 ERROR: Ifr file md4_qnx_display.ifr_new
Jan 01 00:00:00.338    5 10005    14 md4_qt.ifr_newwcorrectedr_new4].ifr_new[2000/
32 errorles to u
EC
Jan 01 00:00:00.338    5 10005    14 md4_qnx.ifr_newfr_new66 Mhz [266/1]ule
ECC Data Bytepos=1a9 Bitpos=
Jan 01 00:00:00.338    5 10005    14 md4_install.ifr_newData Bytepos=be2 Bitpos=1 correctednew
Jan
MPU  DPLL in
Jan 01 00:00:00.338    5 10005    =5d5 Bitpock 800               
Jan 01 00:00:00.338    5 10005    14 libmd4.a.ifr_newcorrected0
Tim
  MPU  clock 800 Mhz [800/1]  5 1000
Jan 01 00:00:00.339    5 10005    14 images.ifr_news/startup.sh: N
  PER  clock 192 Mhz [960/5]336   
Jan 01 00:00:00.339    5 10005    14 i2cdriver.ifr_new86f Bitpos=2
  M4 CORE clock 200 Mhz [2000/10]6    5
Jan 01 00:00:00.339    5 10005    14 fonts.ifr_new[2000/8]ectedor     
  MPU
Jan 01 00:00:
  M6 CORE
Jan 01 00:00:00.339    5 10005    14 devnp-am335x.so.ifr_newng to QNXCC Data Byt
Ja
MD4 QNX startup6    5 10005   
nand
Jan 01 00:00:00.339    5 10005    14 camserver.ifr_news=40 correctedlock


[glenneaux]

I can also pile on a lot.

Code: [Select]

ECC Data Bytepos=32a Bitpos=40 correctedC.ifr_newnewx.so.ifr_new:583 CRC error 
ECC Data Bytepos=1c Bitpos=4 corrected   5 10005    14 vmAC.ifr_newcrc32 for
DDR  DPLL in Lock mode:ifr_05    14 Mod
Jan 01
  DDR  clock 266 Mhz [266/1]4 touchdriver.ifr_new5    5
Disp DPLL in Lock mode:fr_
Jan 01 00:00:00.339
  Disp clock 192 Mhz [192/1]0005    14 spidriver.ifr_new
MPU  DPLL in Lock mode:ver.ifr_new00.338    5
  MPU  clock 800 Mhz [800/1]  5 10005    14 resources.if
PER  DPLL in Lock mode:14 Progress 100n 01 00:
  PER  clock 192 Mhz [960/5]336    5 10005    14 md4_tim
CORE DPLL in Lock mode:ROR: Ifr file md4_qnx_d
  M4 CORE clock 200 Mhz [2000/10]7    5 10005    14 md4_qt.ifr_new
  M5 CORE clock 250 Mhz [2000/8]2 error
Jan 01
EC
Jan 01 00:00:
  M6 CORE clock 500 Mhz [2000/4]fr_new    14 touchdriver.ifr_
E

Jumping to QNXs=be2 Bitpo
Ja
MD4 QNX startup7    5 10005   
nanddriver: devio_readtrans:583 CRC errorpos=80 correctedewogress 100       
Jan 0
Time                 Sev Major 32a Bit                     
Jan 01 00:00:00.337    5 10005    14 vmGC.ifr_newnewio_readtrans:583 CRC error.R  DPLL in Lock mod
Jan 01 00:00:00.337    5 10005    14 vmAC.ifr_newcrc32 for module md4_qnx_display.ifr_05    14 Mod
Jan 01 00:00:00.337    5 10005    14 touchdriver.ifr_new# ECC Data
new started0:00.335   
Jan 01 00:00:00.340 
Jan 01 00:00:00.337    5 10005    14 spidriver.ifr_new invorrected14 libmd4
Jan 01 00:00:00.335    5 10005 
Jan 01 00:00:00.338    5 10005    14 resources.ifr_new.429    5 10005    14 Progress 100n 01 00:00:00.335   
Jan 01 00:00:00.338    5 10005    14 md4_time.ifr_new 10005    14 ERROR: Ifr file md4_qnx_display.ifr_new
Jan 01 00:00:00.338    5 10005    14 md4_qt.ifr_newwcorrectedr_new4].ifr_new[2000/
32 errorles to u
EC
Jan 01 00:00:00.338    5 10005    14 md4_qnx.ifr_newfr_new66 Mhz [266/1]ule
ECC Data Bytepos=1a9 Bitpos=
Jan 01 00:00:00.338    5 10005    14 md4_install.ifr_newData Bytepos=be2 Bitpos=1 correctednew
Jan
MPU  DPLL in
Jan 01 00:00:00.338    5 10005    =5d5 Bitpock 800               
Jan 01 00:00:00.338    5 10005    14 libmd4.a.ifr_newcorrected0
Tim
  MPU  clock 800 Mhz [800/1]  5 1000
Jan 01 00:00:00.339    5 10005    14 images.ifr_news/startup.sh: N
  PER  clock 192 Mhz [960/5]336   
Jan 01 00:00:00.339    5 10005    14 i2cdriver.ifr_new86f Bitpos=2
  M4 CORE clock 200 Mhz [2000/10]6    5
Jan 01 00:00:00.339    5 10005    14 fonts.ifr_new[2000/8]ectedor     
  MPU
Jan 01 00:00:
  M6 CORE
Jan 01 00:00:00.339    5 10005    14 devnp-am335x.so.ifr_newng to QNXCC Data Byt
Ja
MD4 QNX startup6    5 10005   
nand
Jan 01 00:00:00.339    5 10005    14 camserver.ifr_news=40 correctedlock


What is this ?

[Postal2]

What is this ?

This is the QNX startup, stupidly copied from HyperTerminal.

[glenneaux]

What is this ?

This is the QNX startup, stupidly copied from HyperTerminal.

oh ok.

I guess, if I try and get console working at 115.2kbps per your suggestion, I could probably just flash this new bootloader in and see what happens - I probably wont lose the console (maybe).

I believe uboot has a default environment hardcoded into the bootloader as a fallback. Looking at my device, i can see the baudrate=115200 command from the bootloader image - and can see baudrate=19200 in both of my environment partitions, and i know these contain a crc check. Apparently the bootloader itself does not?

If so, inspecting the new bootloader, i can see its baudrate=115200 variable... if uboot does not perform crc check in theory it would be possible to alter this default variable - once in uboot i can manually set the actual environment variables and continue to attempt loading the kernel/device tree image by tftp.

[Postal2]

... Looking at my device, i can see the baudrate=115200 command from the bootloader image - and can see baudrate=19200 in both of my environment partitions, and i know these contain a crc check. Apparently the bootloader itself does not?

I've changed environment variables by directly editing the image and never had problems. This applies to the bootloader, you can set baudrate, change the timeout, and I don't remember what, and it always worked for me.
I don't understand at all what you are doing. You can write everything directly from Linux, using dd with maximum rights. You know how to set 19200. If it doesn't work, then you can figure it out. But first you need to copy the image. Then, before writing a new one, compare visually, usually this is enough. If it stops starting at all, then I would unsolder the nor flash and conduct temporary experiments with the flash in a familiar case. Perhaps I would use JTAG if I had everything configured. Perhaps the chip has a bootrom and it is easier to use.

[langwadt]

What is this ?

This is the QNX startup, stupidly copied from HyperTerminal.

oh ok.

I guess, if I try and get console working at 115.2kbps per your suggestion, I could probably just flash this new bootloader in and see what happens - I probably wont lose the console (maybe).

I believe uboot has a default environment hardcoded into the bootloader as a fallback. Looking at my device, i can see the baudrate=115200 command from the bootloader image - and can see baudrate=19200 in both of my environment partitions, and i know these contain a crc check. Apparently the bootloader itself does not?

If so, inspecting the new bootloader, i can see its baudrate=115200 variable... if uboot does not perform crc check in theory it would be possible to alter this default variable - once in uboot i can manually set the actual environment variables and continue to attempt loading the kernel/device tree image by tftp.

if crc fails you get a warning that the default is used

[glenneaux]

... Looking at my device, i can see the baudrate=115200 command from the bootloader image - and can see baudrate=19200 in both of my environment partitions, and i know these contain a crc check. Apparently the bootloader itself does not?

I've changed environment variables by directly editing the image and never had problems. This applies to the bootloader, you can set baudrate, change the timeout, and I don't remember what, and it always worked for me.
I don't understand at all what you are doing. You can write everything directly from Linux, using dd with maximum rights. You know how to set 19200. If it doesn't work, then you can figure it out. But first you need to copy the image. Then, before writing a new one, compare visually, usually this is enough. If it stops starting at all, then I would unsolder the nor flash and conduct temporary experiments with the flash in a familiar case. Perhaps I would use JTAG if I had everything configured. Perhaps the chip has a bootrom and it is easier to use.

Well I can confirm that editing the parameters through editing the binary worked no worries.

I was able to change the default environment baudrate to 19200 and flash it back in.


My goal here was to get the device onto a production firmware, or at least operating system, so that I would be able to program the device (HMI) with Codesys. Having the production firmware would mean I would have the accompanying codesys library to allow programming.


Since doing that, I built up courage and modified the binary of the production v2.2.2.1, chaning baudrate to be 19200, and flashed it.

Device now has some messages come up on the console at 115.2kbps and uboot doesn't appear.

Next steps - play around with the opamp circuit to get back to 115.2kbps, and then work on rectifying the problem with the new bootloader (unlikely), or, work on getting the old binary reloaded (jtag?)

[Postal2]

...Since doing that, I built up courage and modified the binary of the production v2.2.2.1, chaning baudrate to be 19200, and flashed it.

Device now has some messages come up on the console at 115.2kbps and uboot doesn't appear....

I changed environment variables only for the bootloader. I would have tried system variables, but I had no reason.
I assume that restoring 115200 will show an unrecoverable error and will not be useful. At this point, I would try JTAG, because Xilinx loves it. I have a cable bought on Aliexpress for $25, which supports all chips, like DLC9LP (with the right stuffing). I connected it to ISE 13, ISE 14 under Windows XP, it works absolutely without problems. I don't know anything about your chip. I can only say that the situation with JTAG adapters is the same as with TI, i.e. you can buy an expensive adapter and suddenly find out that it only supports MSP430.

[glenenglish]

Buy a Xilinx Platform Cable II  JTAG pod. There are a few inexpensive options. Maybe just  - the USB pod. USD270.

https://www.xilinx.com/products/boards-and-kits/hw-usb-ii-g.html
Most of the ALiexpress pods are DLC10 - old Platform cable - 1

there might be limited Vivado support for NON XILINX pods.

This aliexpress one might work, worth the USD25 gamble... Not sure it supports 1.8V VCCIO....

https://www.aliexpress.com/item/1005003712446430.html?src=google&albch=search&acnt=479-062-3723&isdl=y&aff_short_key=UneMJZVf&albcp=21520181001&albag=168529894787&slnk=&trgt=dsa-1642801257570&plac=&crea=707748366228&albad=707748366228&netw=g&device=c&mtctp=&memo1=&albbt=Google_7_search&aff_platform=google&albagn=888888&isSmbActive=false&isSmbAutoCall=false&needSmbHouyi=false&gad_source=1&gclid=Cj0KCQiA9667BhDoARIsANnamQa5aOpJKF8IaDPfs3cSx3Wu8pw16owlGeho80B2s0hocRcnKDDTeJAaAj6BEALw_wcB

[langwadt]

Buy a Xilinx Platform Cable II  JTAG pod. There are a few inexpensive options. Maybe just  - the USB pod. USD270.

https://www.xilinx.com/products/boards-and-kits/hw-usb-ii-g.html
Most of the ALiexpress pods are DLC10 - old Platform cable - 1

there might be limited Vivado support for NON XILINX pods.

an FTDI shoudl do, https://www.eevblog.com/forum/fpga/custom-jtag-debugger-for-xilinx-fpgas-based-on-ft22x-chips/