AnsweredAssumed Answered

i.MX6UL refuses to be programmed/debricked

Question asked by Patrick Schneider on Nov 14, 2018
Latest reply on Nov 20, 2018 by Patrick Schneider

Hi folks,
I have a very strange problem. I have a Evaluation-Kit for the i.MX6ul which is working perfectly fine with the imx_usart and imx_usb tools provided here (https://github.com/boundarydevices/imx_usb_loader). I also tried serveral other tools (mfgtools, uuu...) but this one gave the most debug output.

So that is working fine for reference. My setup should be OK and the Barebox Image I'm trying to flash also.
Then I have two prototypes of our custom board who refuse to be flashed either by imx_usb or imx_usart. The USB and Serial interface should both work fine because they work well in our applications on these boards. Both prototypes got flashed with bad bootloaders/kernels during development and probably have broken NAND data. So they boot into the Serial Downloader Mode and I try to "debrick" them. (Side note: same behaviour is witnessed if I solder the boot pins to directly start the Serial Downloader mode)
The imx_usart is giving more debug data so I'll post that output here. This is the working Evaluation-Kit, everything as it should be:

trailing slash == 0x6092c1:/mx6_usb_work.conf
checking with conf_path /usr/etc/imx-loader.d/
checking with base_path ./
config file <.//mx6_usb_work.conf>
parse .//mx6_usb_work.conf
sending command cmd=0505
do_command err=0, last_trans=16
report 3 in err=0, last_trans=4 56 78 78 56
HAB security state: development mode (0x56787856)
report 4 in err=0, last_trans=4 f0 f0 f0 f0
== work item
filename /media/sf_fileshare/tftpserv/barebox.bin
load_size 0 bytes
load_addr 0x00000000
dcd 1
clear_dcd 0
plug 1
jump_mode 3
jump_addr 0x00000000
== end work item
process_header: header_offset=400, 402000d1
loading DCD table @0x910000
sending command cmd=0a0a
do_command err=0, last_trans=16

<<<496, 496 bytes>>>
report 3 in err=0, last_trans=4 56 78 78 56
report 4 in err=0, last_trans=4 12 8a 8a 12
succeeded (security 0x56787856, status 0x128a8a12)
dcd_ptr=0x8000042c
clear dcd_ptr=0x8000042c
skip=0 cnt=4000 dladdr=80000000 file_base=80000000 fsize=680c5 max_length=69000

loading binary file(/media/sf_fileshare/tftpserv/barebox.bin) to 80000000, skip=0, fsize=680c5 type=aa
sending command cmd=0404
do_command err=0, last_trans=16
load_file:foffset=0, cnt=400, remaining=680c5
load_file:foffset=400, cnt=400, remaining=67cc5
and so on and so on.... the rest is programmed fine and the barebox is flashed

and that is the behavior of our custom boards, both the same


trailing slash == 0x6092c1:/mx6_usb_work.conf
checking with conf_path /usr/etc/imx-loader.d/
checking with base_path ./
config file <.//mx6_usb_work.conf>
parse .//mx6_usb_work.conf
sending command cmd=0505
do_command err=0, last_trans=16
report 3 in err=0, last_trans=4 56 78 78 56
HAB security state: development mode (0x56787856)
report 4 in err=0, last_trans=4 33 33 33 33
== work item
filename /media/sf_fileshare/tftpserv/barebox.bin
load_size 0 bytes
load_addr 0x00000000
dcd 1
clear_dcd 0
plug 1
jump_mode 3
jump_addr 0x00000000
== end work item
process_header: header_offset=400, 402000d1
loading DCD table @0x910000
sending command cmd=0a0a
do_command err=0, last_trans=16

<<<496, 496 bytes>>>

and than it just stops, no error or cancel, just stops. The only difference I can see is the status return after HAB security state. Its `0F 0F 0F 0F` on the working board and `33 33 33 33` on the customs. What does that mean?
I never knowingly messed around with HAB, security bootloaders or eFuses for that matter. The only thing I did was programming the Boot-eFuses to boot from internal NAND with 512MB and that was a long time ago.
Is there something I'm doing wrong on our custom boards?
Any help appreciated, best regards,
Patrick

Outcomes