No known issues between firmware revision 8151 and libhpcalcs, but I have no proof that anybody, until you, tried


Good idea for the short term: scripting languages are excellent for prototyping the protocol implementation, and Python has become the most popular scripting language.
For the longer term, like anything but C, it has poor interoperability, and therefore, the stabilized code should be rewritten in C.


Sure, this could do the job.

I'll have to dig into that.


Indeed, I want to at least run commands against it, but probably having MSD be a part of hpcables would be best.

Yeah, and we can grab a bit of code from libticables, for e.g. probing.

Is that part of the nspire code? I am assuming you mean MSD-related probing, not the (e)z80/m68k calcs probing.

I'm thinking of the USB enumeration code, for a start, but probably little beyond that.

I know why libhpcalcs didn't detect the calc, first line should be obvious:
Code:


Guess I should have it detect both PIDs... I hope the protocol didn't change.

<edit> Get info action works now, seems like either the format changed or libhpcalcs didn't parse it properly.

Aha. If the PID changed, of course...
So you were officially the first libhpcalcs user trying to communicate with a Prime calculator running the latest firmware version - or, but that is very unlikely, your Prime is acting weird.

libhpcalcs doesn't attempt to parse the packet returned by the calculator after it receives the "get infos" command.

Prime revalidated the firmware (somehow I triggered that) and still has a new PID.

The get infos command failed in receiving the virtual packet iirc. Adding both PIDs in libhpcalcs picked my calc up just fine.

I sent the firmware 2 more times, now totaling 3 usbpcap dumps. I am seeing that the random data sent by the PC is likely uninitialized data (I am seeing parts of the USB packet being built and other bits) as the data keeps changing (calc zero-initializes). I've updated my MSD wiki page with information on commands used. I still have to get around to sending SCSI commands.

Heh, calc now zero-initializes packets ? It used not to.

From the packet dumps I see with usbpcap, the MSD packets' unused bytes are 0'd, whereas the PC sends whatever's in memory.

Anyways, I just got the test program and hpcalcs to reboot the prime. I just run `dd if=/dev/sdi of=dump.bin bs=16384`, got a 267MB dump back at 9.9 MB/s

I'll have to look at sending now. I'd love to test sending something to it, but need more info on the whole process, like how does the progress bar on-screen know the size it will receive, is it hard-coded? Or is it sent? I'll have to dig that up.

@debrouxl: Also, since you managed to send custom machine code, I recall checksums being involved. Do you know if there is data validation on the OS data being sent?

Yeah, the Prime's USB controller is known to be fast


I don't know who builds progress information. It could be built by the CK on the computer side, given that the size received by the calculator is pretty much the sum of the components.

In order to keep the implementation simpler at first, libhpcalcs is missing libticalcs' progress information support (or rather, something inspired by it, Benjamin and I have been less than fully happy with it for years). In libticalcs, the total data size, used as upper bound for the progress information when sending data, is usually built by the computer side.


When critor sent an modified official firmware (just fiddling with a string) to his calculator, he didn't have to update a checksum. Likewise, my crappy third-party firmware PoC (armfir.elf embedded into the apps disk) contains no checksum. Therefore, I'm not convinced there's data validation (beyond individual packets) on the OS data being sent.

EDIT: in libhpcalcs, for a start, there should be an operation (new field in the function pointers struct) to switch to firmware download mode. "switch_to_recovery_mode" or something like that.

I was playing with SCSI commands in python today trying to figure out how the Prime's Recovery Mode works. I have been able to control the progress bar on the screen, but am still working on it. I've ran into an issue, not sure who to blame, but a command that returns a CHECK CONDITION is getting automatically handled and the Prime gets reset. But that is part of their protocol, windows doesn't do anything crazy with it.

The length of reads to 0xaa defines a command. It seems that to have reads and writes to 0xaa get handled by the recovery mode, you need to READ(10) LBA:0xAA Len: 30. The conn kit does it twice, so do I, but after that, 0xAA responds with a magic number and acts as a command/status address.

With that done, I'm able to advance the progress bar from 0x00 to 0x64. Decreasing does not have any visible change (maybe because the screen isn't getting erased?). Going above 0x64 doesn't glitch up, don't know if it ignores or jumps to the end.

I haven't been successful with the finalization/reboot command yet, nor have I attempted to do any writes.

Once I have enough info, I could add this to hpcables. What do you think, should the prime in recovery mode be added as a new cable/model? You could reuse some of the same commands possibly? But flashing will probably need its own new command, can't really hijack file sending commands.

It's definitely a new cable, and quite possibly a new model as well.


Yeah, there's low potential for reuse, and flashing needs its own new command.

Nudged by KermM: I updated my MSD wiki page with the information I found from experimentation in my last post.