Post Reply 
Native G2 programming
05-18-2021, 05:17 PM
Post: #1
Native G2 programming
A while back, before the release of the Prime G2, GitHub user boricj made a custom firmware for the G1. I was wondering if this would also work on the G2 model, or if it would result in the calculator being bricked.

Thanks,
jfelten
Find all posts by this user
Quote this message in a reply
05-19-2021, 04:35 AM (This post was last modified: 05-19-2021 04:35 AM by Tim Wessman.)
Post: #2
RE: Native G2 programming
You would not even be able to load it in any way. No, it will not work. Different hardware and chips.

Nor would any bad firmware ever "Brick" anything. Both chips allow you to flash them even without any firmware inside by bootstrapping code into the device.

TW

Although I work for HP, the views and opinions I post here are my own.
Find all posts by this user
Quote this message in a reply
05-19-2021, 09:50 AM
Post: #3
RE: Native G2 programming
As Tim said, Rip'Em won't work on the HP Prime G2. Besides, thanks to its more modern & well-supported System-on-Chip other people managed to port all kinds of stuff to that machine (https://www.hpmuseum.org/forum/thread-13953.html), there's no need to mess with that kludgy mess anymore.
Find all posts by this user
Quote this message in a reply
05-19-2021, 02:21 PM
Post: #4
RE: Native G2 programming
What happens if you try flashing linux to the calculator without putting it in SDP mode?
Find all posts by this user
Quote this message in a reply
05-19-2021, 04:37 PM
Post: #5
RE: Native G2 programming
(05-19-2021 02:21 PM)jfelten Wrote:  What happens if you try flashing linux to the calculator without putting it in SDP mode?
The upgrade mechanism on the HP Prime G2 will reject firmwares not signed by HP. However, the calculator does not enforce a root of trust on boot, so you could just replace the official firmware with something else after putting the calculator in SDP mode and booting unofficial software.
Find all posts by this user
Quote this message in a reply
05-19-2021, 05:51 PM
Post: #6
RE: Native G2 programming
Do you only have to do this once, or is it required any time you flash new 3rd-party firmware to the calculator?
Find all posts by this user
Quote this message in a reply
05-19-2021, 07:59 PM
Post: #7
RE: Native G2 programming
(05-19-2021 05:51 PM)jfelten Wrote:  Do you only have to do this once, or is it required any time you flash new 3rd-party firmware to the calculator?
The HP Prime G2 does not enforce a root-of-trust, the official firmware only enforces a chain-of-trust. If you actually replace the official firmware on the NAND Flash with something else then on the next boot whatever restrictions the official firmware has is no longer relevant because it's no longer there*.

*Except if HP decides to enable the root-of-trust stuff on the SoC in a future firmware update, in which case it will refuse to boot anything that isn't signed by HP.

If you do not replace the official firmware, then it will be launched on the next boot unless you do the SDP dance again.
Find all posts by this user
Quote this message in a reply
05-19-2021, 08:40 PM
Post: #8
RE: Native G2 programming
What do I need in order to be able to go about writing my own firmware for the Prime?
Find all posts by this user
Quote this message in a reply
05-20-2021, 03:43 PM (This post was last modified: 05-20-2021 03:44 PM by Jean-Baptiste Boric.)
Post: #9
RE: Native G2 programming
(05-19-2021 08:40 PM)jfelten Wrote:  What do I need in order to be able to go about writing my own firmware for the Prime?
Mostly the same stuff you need for embedded device work: an ARM Cortex-A toolchain, tooling for the i.MX6ULL SoC (publicly available for the most part), either a 3.3v TTL UART adapter or a 3.3v TTL JTAG adapter, documentation about the SoC/hardware, low-level programming skills, maybe sysadmin skills if you're using something like Buildroot, basic electronics knowledge if you end up soldering stuff... Also a fair amount of free time.

I will not go into more details than that because either you already have done embedded device work before and you should know what to do/expect in general, or you haven't and you really should start with an easier, well-documented target like a Raspberry Pi or a BeagleBoard (or an i.MX6ULL evaluation kit if you really want to start on a related platform) rather than jumping head-first on an obscure, undocumented, proprietary hardware platform without that kind of support from the manufacturer.
Find all posts by this user
Quote this message in a reply
Post Reply 




User(s) browsing this thread: