Quote from: Lionel Debroux on March 08, 2016, 01:31:47 PM
Indeed, we already knew it.

Better than knowing it, now we can use it. Besides other things I figured out the subroutine that reads a NAND block, so now I can either write a reimplementation or piggy-back the existing one for Rip'Em.

Quote from: Lionel Debroux on March 08, 2016, 01:31:47 PM
What about the TI-Planet hpwiki, which already contains such kind of material, as well as other content unmatched elsewhere (not even in the HP community), that I know of ?
See https://tiplanet.org/hpwiki/index.php?title=User:BXCBOOT0_BIN_pastebin_com_SKw5xtev , dropped by an anonymous user in August 2013.

I used that page as a starting point, but I've done my reverse-engineering with only arm-none-eabi-objdump since I don't have IDA. I've requested an account, now waiting for the email.

By the way, why is the HP wiki separate from the main TI-Planet wiki and why does it require a separate account from TI-Planet's ? It's not very practical and the HP pages are needlessly hidden away...

Yeah, Windows-only flashing sucks, but I don't think I'm up to the task of reverse-engineering the USB flashing protocol. I only have so much sanity to spare

On the other hand, I've reverse-engineered a good chunk of the first 8 KiB (only 2 KiB worth of code, but still) of BXCBOOT0.BIN. There's enough stuff to piggy-back here to allow unlimited read access to the NAND.

It is acceptable to post such material here or should I put it somewhere else ?

Quote from: DJ Omnimaga on March 08, 2016, 12:19:29 AM
Would this qualify as safe? I am curious because while under normal means I wouldn't mind sacrifying a calculator to test an OS for compatibility, I am currently short on money for new calculator purchases, so I am reluctant about taking the risk with my only HP Prime.

Beyond the "decline any responsibility" disclaimer, Rip'Em doesn't touch the NAND at all except for turning on (irrevocably until reset) write-protection for the recovery as the very first thing done, so a brick is theoretically impossible. I'd qualify it as safe.

The reckless part is about opening a HP Prime to connect to the UART and probe the GPIO registers through the GDB stub until something interesting happens. My calc has suffered no side effects, but I wouldn't recommend nor ask anyone to do that.

The dumper firmware merely dumps the contents of the GPIO registers on the screen, no reckless probing here. With screenshots running on different hardware revisions, I can hopefully pinpoint some differences between the revisions and code accordingly.

Dumper's done. Hopefully without bugs.

It's in the gpio-dumper branch on the GitHub repository. I took a picture on my HW-C calc and attached the results.

Odd. I have a HW-C model though.

I hope it's just the keypad matrix being connected to different GPIO pins. A DVT model is too precious to sacrifice FOR SCIENCE! tinker recklessly with its UART.

Previously, I (ab)used the external interrupt pin hooked to the ON key, but I switched to the proper scanning method when I got it working.

I'll make a firmware to dump all GPIO registers on the screen. Since BXCBOOT0.BIN initializes the keypad GPIO to read the ON+Symb key combination, with a bit of luck the configuration registers will tell me where the keypad pins are located.

New stuff added since last time :

• Complete keypad support ;
• gzip-compressed payloads ;
• Graphical menu to select a payload to launch ;
• Dumb integer RPN calculator demo, complete with 26 (a-z) variables.

The ability to boot the original firmware is crippled for now (only booting the diagnostic screen works).

I have now run out of simple things to implement. I can't push this thing any further without first porting a real-time operating system and making a USB GDB stub...

Quote from: Juju on January 01, 2016, 11:51:45 PM
That's pretty awesome, hope someone writes a full OS for it, like KnightOS or even something Linux-based.

I personally plan to port NetBSD on it someday. The author of newRPL also showed interest in the HP Museum forum, however for now he's worried that developing for the Prime would set back newRPL by months or years due to lack of manpower.

Quote from: DJ Omnimaga on January 02, 2016, 04:05:28 AM
Do you think dual-booting will be possible?

I can chainload the original PRIME_OS.ROM with the osrom2elf tool. Booting another operating system such as Linux or NetBSD should be possible, though for now anything over 1 MiB (size of PRIME_OS.ROM) has to be uploaded through the serial port.

Dual-booting with the original firmware should be doable. However, unless you use USB Mass storage I guess the only safe place to store data would be inside the FAT16 partition in PRIME_APP.DAT. I don't know how much stuff can be removed and still have the original firmware working, but I wouldn't bet on having more than 22 MiB available.

Well, it's not really an announcement anymore since the news spread to every major calculator website community, but I thought I should create a topic here just for good measure.

From the original Omnimaga thread (https://www.omnimaga.org/hp-prime/announcing-rip%27em-a-third-party-firmware-for-the-hp-prime/) :

Quote
Ran out of presents to rip open? How about ripping open your HP Prime for science?

This is Rip'Em, a third-party firmware for the HP Prime calculator. It is a (rather primitive for now) unofficial bootloader that replaces PRIME_OS.ROM and is currently written by someone who doesn't know what he's doing.

For now, unless you can connect to the 3.3v TTL serial port inside the calculator nothing too exciting will happen.

What you can do with it for now :

• Launch a homegrown GDB stub over serial (only suitable for poking memory and upload/run code) ;
• Launch a single ELF file as a payload. Current payloads available are :
  
  
  
  • dummy.elf : A dummy payload that blinks the LEDs so you can hang your HP Prime to your Christmas tree ;
  • PRIME_OS.ROM : The official firmware can be launched using the osrom2elf tool supplied.
• Write your own application on bare metal using the libraries supplied.

Current plans and what you can do to help :

• Play around with Rip'Em ;
• Use the GDB stub to figure out the hardware ;
• Replace the homegrown GDB stub with the real stuff ;
• Write a USB serial driver to enable the GDB stub to work over it ;
• Add the ability to have multiple payloads, to read payloads from the FAT16 partition in PRIME_APP.DAT and to select a payload with a simple graphical user interface.

Non-goals (at least for me) :

• Reverse-engineering, patching or otherwise tampering with the official firmware. The TODO list is already big enough to keep me busy for a long time ;
• Bloat within RIp'Em itself. It's an ELF launcher, not a operating system. Even the GDB stub should be demoted as a payload eventually.

Source code available over at https://github.com/boricj/ripem. Kudos to Lionel Debroux for being the first one to run a third-party firmware on the HP Prime.

As always : please void your warranty in a responsible manner. I will decline any responsibility should you turn your HP Prime into the thinnest CAS calculator brick available currently on the market.

Since I wrote this post the dummy payload has been updated to display the current time on the LCD screen. So now even without connecting to the serial port inside the calculator slightly exciting stuff will happen.

Next goal is the keypad.

Hi all,

I'm a French student with way, way too much time on its hands. There's about a bazillion HP calculators in my house, and I personally own a TI-82 Stats.fr and a HP Prime.

Also I'm the guy behind Rip'Em, the third-party firmware for the HP Prime.