LS1046A JTAG Programming in Production

[smiller2]

We are moving into the production phase of our board using the LS1046A.    It is booting from QPSI.  We need to program that QSPI chip after assembly.   We have the standard 10 pin JTAG header on the board and previously programmed via Code Warrior.    However, Code Warrior is too expensive and cumbersome for a production environment.  

What other tools can be used just to program the QSPI and get the board to boot?   We only need to load three files,  RCW, ATF, and the Ethernet driver.    I can probably concatenate those into a single blob file.  

Is there support for this from something like OpenOCD using the CMSIS-DAP  interface? 

Thanks.

[dykeag]

@smiller2 

We are facing the exact same issue. Can you share what solution you came up with? 

[stadium_aquino]

https://u-boot.readthedocs.io/en/latest/board/nxp/ls1046ardb.html#jtag-boot

[smiller2]

Unfortunately, there was no good solution to this.   Our manufacturing uses a single PC to perform the initial programming.   On this PC, they have an evaluation copy of CodeWarrior.   Every time that the evaluation copy expires, then they erase the hard drive of the PC,  install the OS again, and load another evaluation copy.    Very time consuming. 

[dykeag]

Oh man, that is awful. 

I am currently looking into the OpenOCD solution myself, which is how I came across this thread.

My thinking was that we could use literally any other JTAG probe (probably a Digilent because we have a dozen of those floating around the office) and use OpenOCD to do the initial programming.

I noticed that in May of 2022, a commit was added to OpenOCD which added support for the ls1046a. The change appears to consist of a single configuration file. I have my doubts that this will work out-of-the-box for either of us, but it does appear to be a starting point. In particular, I don't see how OpenOCD sets the RCW or anything else that those CodeWarrior python init scripts do (DDR timing, etc). I dread trying to figure this out myself, especially considering the absolute nightmare NXP created with all the peripherals on this processor having different endianness. 

The OpenOCD commit: https://review.openocd.org/c/openocd/+/6854/4

If I come up with anything workable, I'll be sure to let you know. 

-- dykeag

[dykeag]

Update: We never found a solution to this issue. We ended up getting our flash memory pre-programmed from the vendor before we place them on the board

[stadium_aquino]

Did you try the semihosting thing?

[dykeag]

I did, and I did get it working somewhat. 

What I was never able to do was override the RCW without using CodeWarrior. 

[stadium_aquino]

Well, what I always did was flash a minimal image with just SPL+U-Boot+FMan ucode and then reboot. That way I could download the main image over Ethernet.

Although, you should have a look at https://lore.kernel.org/linux-arm-kernel/20230810102631.bvozjer3t67r67iy@skbuf/  which has how to override the RCW. I haven't tested it yet.

[dykeag]

I never saw that - that is exactly what I'm looking for!

It really irks me that NXP purposefully didn't document how to override the RCW - a feature which is fairly essential to board bringup. 

[ufedor]

There are no direct recommendations to use specific tool for production SPI Flash programming. In general any debugger tool could be used. Possible alternatives to CodeWarrior are tools from Lauterbach, Wind River, Green Hills.