I'm hoping someone can help, but there is quite a story so please bear with me.
I have a board that I can use mfgtool (v1.6.2.032) that uce_ivt.sb and eboot_ivt.sb go in fine, but I get errors on NK.nb0.
5 - Panel A Start <CMD/> type="push" body="fwtype:NK_NB" file="" timeout="10" onError="" text="Specify firmware type.". 5 - Panel A Finished <CMD/> type="push" body="fwtype:NK_NB" file="" timeout="10" onError="" text="Specify firmware type." SUCCESS code=0. 5 - Panel A Start <CMD/> type="push" body="send" file="files/nk.nb0" timeout="10" onError="" text="Sending a firmware file.". 5 - Panel A Finished <CMD/> type="push" body="send" file="files/nk.nb0" timeout="10" onError="" text="Sending a firmware file." FAIL code=-1. Panel A: Updater Error 0xffffffff (-1) -
I've looked at the mfgtool SRC for v1.6.2.055 and I can see that the return value of -1 is set by retValue = m_pUTP->UtpWrite(csCmdBody, fullFileName, callback); in OpUtpUpdate.cpp, however I don't understand why.
UtpWrite will either return ERROR_OPEN_FAILED (110L), ERROR_INVALID_HANDLE (6L) or whatever gets set in cmdProgress.error (((DoneState*)transaction.GetCurrentState())->GetResponseInfo()).
GetResponseInfo returns m_ResponseInfo which I can only see as being set inside the constructor of DoneState. The only references to DoneState include the values -65535 (Polling stalled), -65536 (Illegal response code), or (m_pCurrentState->GetUtpMsg()->GetResponseInfo()).
My understanding could be completely wrong, but I should be able to view the UTP messages using capture software (like Wireshark and USBpcap) so somewhere there should be a -1 in GetResponseInfo(). GetResponseInfo() just takes the 4 bytes of ScsiSenseData.Information, flips the order and puts it in UInt32.
I've run Wireshark and USBpcap but I am struggling to tie everything together. I can see the host sending the push commands (MediaType:NAND, QueryStoreNameLNAND FLASH Storage,Timeout:10, wfw, fwtype:EB_SB, send). This is followed by 10 packets 65563 bytes long, something weird, 1 packet 2507 bytes long, and then the save command. The something weird is that a normal transfer is as follows:
Host->Device SCSI Command: 0xf0 LUN:0x00 Host->Device SCSI: Data Out LUN: 0x00 (0xf0 Request Data) Device->Host SCSI: Response LUN: 0x00 (CDB:0xf0) (Good)
But the weird bit was that after 10 packets instead of sending SCSI Command: 0xf0 LUN:0x00 we see the following:
Host->Device SCSI: Test Unit Read LUN: 0x00 Device->Host SCSI: Response LUN: 0x00 (Test Unit Ready) (Check Condition) Host->Device SCSI: Request Sense LUN: 0x00 Device->Host SCSI: Data In LUN: 0x00 (Request Sense Response Data) Device->Host SCSI: Response LUN: 0x00 (Request Sense) (Good)
Obviously after the weird bit we send another packet, so I don't know what caused that to happen, or it is just part of normal SCSI operation.
Finally we send the following push commands (save, wfw, fw_type:NK_NB, send)
We successfully send 28 packets 65535 bytes long before doing the Request Sense stuff, but then everything must be good as we carry on and send another 12 packets.
We then do the Request Sense Stuff again with the same response information but it just resends over and over again. I cannot see why this would cause anything to fail, but it clearly does.
At this point mfgtool stops and returns error -1. This happens over half of the time, and always fails at the same point.
Sorry for the long post but I need an answer on this. I've tried building mfgtool 1.6.2.055 from source but it wouldn't build for me.