i.MX6UL refuses to be programmed/debricked

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

i.MX6UL refuses to be programmed/debricked

715 Views
patrick_schneid
Contributor I

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

Labels (1)
0 Kudos
2 Replies

484 Views
patrick_schneid
Contributor I

Thank you Victor for your answer, but that is merely a workaround and unfortunately not helpful in my situation. I need to find and understand the root cause of the problem here to be able to solve and prevent it from happening again.

Has nobody any idea on what could cause such a behaviour?

Best regards,

Patrick

0 Kudos

484 Views
b36401
NXP Employee
NXP Employee

Do the board have SDcard socket? Please try to boot from SDcard instead.

0 Kudos