Linux/66AK2L06: NOR flash update failed and cannot recover or boot to Linux

If anyone has a similar problem, uses google to find help, and finds this question, here is a solution that I discovered. (This is me responding to my own question, because no one from TI responded to it after a week of waiting.)

After several failed attempts to recover the NORflash based on following various TI web pages, I went back and carefully used the "setup.sh" script that comes with ti-processor-sdk-linux-k2l-evm-04.02.00.09.

For other newcomers to this platform, here are a few things that are helpful to know. I am currently using a TI 66AK2L06 SOC, with an "EVLK2L Evaluation Module". The box has the designator "TCIEVMK2LX". I installed a fresh copy of Ubuntu 16.04 LTS on a 64-bit laptop. If your setup deviates in any way from this, the following advice may not be helpful. I have found a huge amount of TI and other web sites that give wrong and/or out-of-date information for parts or setups that are "almost the same" as the system I am trying to get up and running.

- *Definitely* use the USB cable to connect the small USB slot just under and to the left of the eval board LCD to a USB connector on your Linux box. This will create /dev/ttyUSB0 and /dev/ttyUSB1 on your linux box when both sides are powered on. (If you do not see these /dev devices, ignore the rest of this note and go figure out why.)

- Make SURE that you have the lower cat-5 connector on the dev board attached to an ethernet collision domain that has an active DHCP server available. Make sure that your development linux system is also connected to that collision domain, and has an IP address that is on the same subnet as the one that the DHCP server is configured to give to DHCP clients (easiest way to do this is to have your development system configured to get an IP address via the DHCP server).

- I found that the ./setup.sh script was wrong or misleading in several places, but after a fair amount of effort I eventually was able to use it. The way I got it to work was to initially use sudo: "sudo ./setup.sh". It will ask you for your user name, with a default option of "root". I gave it my actual user name. It will say it has to 'apt install' several packages. This step will fail. It will give you two options to manually 'apt install'. Terminate setup.sh, and manually do 'sudo apt install ' on the second of the listed options.

- Then, rerun setup.sh. This time, you should get past the 'install packages' step.

- Allow setup.sh to do all of the things it requests, including setting up /tftpboot and the nfs server on your development system.

- It wll ask about console terminal on the SOC, and suggest /dev/ttyS0. Give it /dev/ttyUSB0 instead. The script will later auto-detect that /dev/ttyUSB0 is for the embedded linux, and /dev/ttyUSB1 is for the BMC controller. So, it may be that you can leave it with this wrong/invalid default. Not sure about this; I do know that giving it the ttyUSB0 option will work. When I was originally using the serial board connector labeled "D" on the dev board Quick Start Guide, the setup.sh script kept trying to use /dev/ttyUSB0 for both the embedded linux console and the BMC controller, and then later failing because, well, you can't use the same /dev/ device for both.

- Say "Yes" to subsequent sequence of questions, you do want to have setup.sh re-install and update your boot loader.

- I also said "Yes", and let setup.sh re-configure the boot process to use targetNFS on my linux host machine. You may be able to decline this option, and also decline the option to have setup.sh re-flash the embedded NAND file system. I have not tried this path, and have found that the TI software is very fragile if you deviate at all from the one "happy path" that they have tested.

- The script will create minicom scripts automatically, and then re-flash the system. This is the key thing that it does on its own that (ahem) saved my bacon and recovered my bricked SOC.

The download and reflash of the NAND file system to an extremely long amount of time - didn't time it exactly, but it seemed like it was on the order of an hour.

After the entire process is complete, setup.sh is just stuck with an open minicom window, at a boot process that appears to have failed. But, you are probably at this point OK, with an intact, restored, and updated NOR flash. I manually exited from the minicom window, and manually terminated the hung setup.sh script.

I rebooted, and the system acquired the NFS file system on my development machine and booted fine from there.

So, Happy Ending to worrisome story!

Overall, it has been a very painful and time-consuming process to get this system up and ready for development. I still have a few unresolved issues, such as how to cross-compile and build Linux binaries on the development platform. As best as I can tell, the gcc compiler on the SOC is configured differently than the gcc cross compiler available in the ti/gcc-arm-none-eabi-6-2017-q1-update directory provided by TI. I can get (for example) MessageQBench.c to compile on the embedded native gcc compiler (after a fair amount of manual configuration of products. mak), but cannot compile MessageQBench.c on the development system with the cross compiler. I will submit a question to e2e.ti.com about that, but I have not gotten a single response to three postings to 2e2.ti.com, and so I'm not sure if anyone is monitoring it and responding to questions from users.

Good luck!

Greg Johnson