Third-party firmware PoC...
|
07-05-2014, 09:17 PM
Post: #1
|
|||
|
|||
Third-party firmware PoC...
After recently buying a Prime, I've now spent several hours making my own armfir.elf. The result is attached.
The code fills one third of the screen with red, one third with green, and the last third with blue (with some glitches...), then enters an infinite loop. Yeah, this PoC sucks, I know - it sucks just as much as my Nspire DummyOS did, more than three years ago. Usage: copy the armfir.elf file into APPSDISK.DAT. Firmware transfer, enter recovery mode by pressing the Reset button in the hole on the back, pressing the Symb key, releasing the Reset button, and holding Symb until the Recovery mode screen appears. Then, use usbtool (Windows only). As usual: works for me, but use at your own risk |
|||
07-05-2014, 11:28 PM
(This post was last modified: 07-05-2014 11:28 PM by alexzkter.)
Post: #2
|
|||
|
|||
RE: Third-party firmware PoC...
Kitkat or Android L?
Jokes aside, thanks for sharing |
|||
07-06-2014, 12:02 AM
Post: #3
|
|||
|
|||
RE: Third-party firmware PoC...
Cool!!!
My website: ried.cl |
|||
07-06-2014, 06:50 AM
Post: #4
|
|||
|
|||
RE: Third-party firmware PoC...
critor was kind enough to shoot the picture I couldn't make yesterday evening:
http://tiplanet.org/forum/gallery/image_...ge_id=3707 We've known from the beginning that on the Prime, Linux would be easier to port than it was on the Nspire, because the S3C2416 has a public datasheet, and is already largely supported by Linux. Some outdated forks of QEMU contain support for the S3C241x and S3C244x series. TI-Planet's hpwiki contains pointers to those. Porting Linux to the Prime requires more technical skill than my PoC, which represents only several hours of work, and didn't learn me much in the way of new things (the -n flag for ld, the --set-start flag for objcopy, and that's about it), because I had already done DummyOS for my OSLauncher on the Nspire. Before porting Linux, we need to somehow obtain more information on the pin assignments (e.g. GPIO for the keyboard ?), through reverse-engineering and/or help. BTW, feature request for the forum: the permission to attach .tar.bz2 files |
|||
07-07-2014, 08:19 AM
Post: #5
|
|||
|
|||
RE: Third-party firmware PoC...
Hey! little question, what happens if you upload a broken elf file? does the firmware utility always recover the calculator to the "upload" mode?
Maybe there is a similar kit to play with in a more comfortably way? like: http://www.ebay.com/itm/ARM-ARM9-linux-s...2a3aedff34 My website: ried.cl |
|||
07-07-2014, 08:43 AM
Post: #6
|
|||
|
|||
RE: Third-party firmware PoC...
Quote:Hey! little question, what happens if you upload a broken elf file?If the code crashes, the calculator reboots. However, I haven't tried to upload flat out invalid ELF files (wrong sections, wrong loading addess, wrong start address, etc.), as it doesn't make much sense. You can try for yourself Quote:does the firmware utility always recover the calculator to the "upload" mode?Holding Symb before and after releasing the Reset button should always be able to recover the calculator, indeed. That is, unless one destroyed the area where the contents of BXCBOOT0.BIN are stored, triggering intentional bricking. Quote:Maybe there is a similar kit to play with in a more comfortably way?Yeah, there are several S3C241x/S3C244x-based kits around, but there's no way they have the same GPIO assignments as the Prime has, so they wouldn't fully help. A computer-based emulator would help, I've gathered several relevant links on the TI-Planet hpwiki. |
|||
07-07-2014, 08:58 AM
Post: #7
|
|||
|
|||
RE: Third-party firmware PoC...
I don't imagine porting Linux to the prime would be all that difficult.
I'm not sure of the utility of doing so however. - Pauli |
|||
07-07-2014, 01:01 PM
(This post was last modified: 07-07-2014 01:06 PM by cutterjohn.)
Post: #8
|
|||
|
|||
RE: Third-party firmware PoC...
(07-05-2014 09:17 PM)debrouxl Wrote: After recently buying a Prime, I've now spent several hours making my own armfir.elf. The result is attached.There's a thread about prime hacking @ omnimaga that recently became more active again. Parisse even deigned to make a few replies, more or less along the lines of I can't tell you much about how the proprietary firmware works, but I can probably drop hints to help hacking, or so I read it. [EDIT] Seems like omnimaga's down ATM, but this SHOULD be the link to the thread: http://www.omnimaga.org/hp-prime/let%27s...rime!/210/ [/EDIT] |
|||
07-07-2014, 02:02 PM
Post: #9
|
|||
|
|||
RE: Third-party firmware PoC...
(07-07-2014 01:01 PM)cutterjohn Wrote: Parisse even deigned to make a few replies, more or less along the lines of I can't tell you much about how the proprietary firmware works, but I can probably drop hints to help hacking, or so I read it. I just read that thread, I didn't see Bernard Parisse making any posts, though. But Cyrille did (unless they secretly are half-brothers, Cyrille's last name is not Parisse). It's funny to see how they refer to Cyrille (quoted from the moderator): Quote:To be honest I am unsure, since he is posting in this particular thread and the HP staff can't really help us hack their own products, but we never know, since TI-Planet and MoHPC have an HP guy named Cyrille. The "HP staff" has collaborated with the HP community for a very long time, even before they became "HP Staff". If I remember correctly, it was Cyrille who published the grayscale demo showing how to execute ARM code in the 49G+, which opened the door for the development of hpgcc and hpgcc3. So, to our fellows from Omnimaga: Yes, you should listen to the "guy named Cyrille", if he offered to help you hack the calc, you better take his advice. In any case, total firmware replacement is tough, it will be a while before something useful can be made with this. It would've been better to provide some kind of hook to add custom functions (apps?) to the existing firmware, much like the HP 50g had hidden opcodes to call arbitrary ARM code from within the emulated environment. But since that would get the Prime banned from all exams... I don't think it will ever happen. This opens the door for somebody to create a custom firmware, and we happen to be creating one. The Prime hardware could be an excellent target for newRPL to run on, but for now I think we'll stick with the 50g platform for the time being. If by the time newRPL is released, there's more information and low-level drivers done for the Prime hardware, then we might attempt to port newRPL to it. Claudio |
|||
07-07-2014, 06:21 PM
(This post was last modified: 07-07-2014 07:10 PM by debrouxl.)
Post: #10
|
|||
|
|||
RE: Third-party firmware PoC...
critor and I are fully aware of who Cyrille and Tim Wessman are
Maybe I've discussed with them through other means of communication for libhpcalcs and/or this PoC, who knows. Low-level Prime development started at Omnimaga indeed... It could still be there, but discouraging several high-profile members from participating to Omnimaga was not a good thing to do for them. The door has always been open for everybody to make a custom third-party firmware (we mostly knew it from Tim, it was proved in early November 2013 by critor, after the same experiment I devised in August failed spuriously), it's just that nobody happened to ever spend several hours of work on it before I did (a couple weeks after buying a Prime), which is a real shame Yesterday, I spent a bit of time porting a starfield effect demo to the Prime, but the results are surprising, and possibly not unrelated to the fact that the three colored areas are slightly shorter than they should be. |
|||
07-07-2014, 07:21 PM
Post: #11
|
|||
|
|||
RE: Third-party firmware PoC...
(07-07-2014 06:21 PM)debrouxl Wrote: critor and I are fully aware of who Cyrille and Tim Wessman are The S3C2416 is very similar to the S3C2410 used in the 50g, but the LCD controller with 2D accelerator is new, so I'm not sure I can help you there, but I'll try to give you some hints. Your first step should be to write a firmware that reads and interpret the contents of VIDCON0, VIDCON1, etc. (I'm assuming you already have the S3C2416 reference manual, if not that's your first thing to do). From there you can get the virtual screen size, base address, etc, more important PAGEWIDTH and OFFSIZE for your window. Since your bands are shorter than you expect my first guess is that it's because the scan length (PAGEWIDTH+OFFSIZE) is larger than the width of the screen. You can get the information from those registers, and adjust your code according to the LCD controller settings (of course, you could also try to program the LCD controller to whatever you want). I think it's great that other communities, be it TI Planet, Omnimaga or others, are taking interest in HP calculators. Those communities have a lot of much needed young talent with a lot of time to spare. Keep hacking and sharing, and we'll keep an eye on your progress. Claudio |
|||
07-07-2014, 07:50 PM
Post: #12
|
|||
|
|||
RE: Third-party firmware PoC...
At first, I didn't change the values of the LCD controller registers, and nothing was displayed on the screen - but it might have been because of a blunder elsewhere, and maybe my setting of the three main registers (start, end, size for window 1) does more harm than good after all. I'll check again later.
I fully agree about the usefulness of making a hardware ports dumper. That's precisely what was done with the Nspire CX (CAS). At first, on the Prime, the data should be displayed on the screen (we already know how to do that), so itoa + A1R5B5G5 sprite routines + font data are required. No biggie, but I won't have much time until Friday, at best... Other people should join the fun OT: wait... you're one of the developers of HPGCC(3), among other things, aren't you ? I used to be a contributor to the dead TIGCC, and I'm the GCC4TI maintainer, even if I'm basically doing nothing anymore, because TI-68k native code programmers have been very few, for several years. |
|||
07-07-2014, 08:04 PM
Post: #13
|
|||
|
|||
RE: Third-party firmware PoC...
(07-07-2014 07:50 PM)debrouxl Wrote: At first, I didn't change the values of the LCD controller registers, and nothing was displayed on the screen - but it might have been because of a blunder elsewhere, and maybe my setting of the three main registers (start, end, size for window 1) does more harm than good after all. I'll check again later. Or... you can just draw 32 white and black squares per register, maybe 4x4 pixels each, just enough for you to be able to read them as binary numbers and convert with a calculator (or, as I prefer, in groups of 4 pixels it's easy to convert to a hex digit in your head). That way all you need is to draw B/W squares, no sprites, no fonts. That should be enough to get you some useful values. (07-07-2014 07:50 PM)debrouxl Wrote: OT: wait... you're one of the developers of HPGCC(3), among other things, aren't you ? Yes, I am. Same thing happened on the HP side: very few people coding in C, I just keep the website up and running and from time to time I test to see if the tools and libraries build with the latest GCC compiler. But now the new plan is to use all the low-level drivers from hpgcc3 to build a new firmware from the ground up for the 50g, not too different from what you are doing on the Prime, actually. Claudio |
|||
07-08-2014, 06:33 AM
Post: #14
|
|||
|
|||
RE: Third-party firmware PoC...
Hello,
"if he offered to help you hack the calc, you better take his advice" Neither I, nor Tim offer, nor will offer help in 'hacking' the calc... As you can imagine, this is somehting that our position within HP does obviously not allow us to do. Please be careful when talking about us as what you say might be mis-interpreted and prove detrimental to us, which I am assuming is not something that you want. You already have access to all the published documentation, and we will happily help by providing information which is not confidential, but might not have been published in user guides due to various constraints (such as the high level spreadsheet data format in order to transform old spreadsheet to new ones, optional command parameters which might not yet have been described...), but we will not do more than that. Cyrille |
|||
07-08-2014, 01:47 PM
Post: #15
|
|||
|
|||
RE: Third-party firmware PoC...
(07-08-2014 06:33 AM)cyrille de brébisson Wrote: Hello, I meant hacking in the sense of 'tinkering', or 'exploring', not in the bad meaning of the word. Here's the Wikipedia definition of Hacker (hobbyist) that I was referring to: Quote:In home and hobby circles, a hacker is a person who enjoys exploring the limits of what is possible, in a spirit of playful cleverness. debrouxl's 3-color bars firmware demo is, in my point of view, an example of 'hacking' in a spirit of "playful cleverness". I didn't mean to get anybody in trouble (only for using that word?). The only reason I used the word 'hacking' is because the thread at Omnimaga has exactly that word in the title. Your post offering help was very clear in what you can or can't do: http://www.omnimaga.org/hp-prime/let's-h...#msg387959 Full firmware replacement falls within the "anything else" in your post, and is clearly not 'hacking the Prime application', but it can very well be called 'hacking the calc', the way I wrote it without getting you in trouble. In any case, I had contact with you in the past, and I also worked with Tim a few years ago (he wasn't at HP back then). I wouldn't knowingly try to get either of you in trouble. Claudio |
|||
07-08-2014, 06:42 PM
(This post was last modified: 07-09-2014 06:10 AM by debrouxl.)
Post: #16
|
|||
|
|||
RE: Third-party firmware PoC...
Two ways to accelerate discovery of the hardware:
* the UART would make for a more productive means of dumping hardware ports than drawing sprites (characters, or squares, good suggestion) on the screen. Unlike the Nspire's UART, the Prime's UART is not directly accessible from the outside. Who to punch a hole in the back cover of his/her calculator, so that the UART can be accessed without having to keep the PCB outside the case ? * perform far more reverse-engineering on the Prime's software than was done until now. Last summer, somebody anonymously posted a bit of work for the very beginning of BXCBOOT0.BIN at http://tiplanet.org/hpwiki/index.php?tit...m_SKw5xtev - and nothing since then. Reverse-engineering would make it possible to take advantage of the syscalls used by the standard armfir.elf. It's pretty easy to see that unlike the Nspire's OS, armfir.elf isn't standalone, without even looking at the code. With my dummy armfir.elf, pressing ON while the calculator is inside the infinite loop turns it off, and pressing ON again will resume the calculator... somewhere. Reset required to give back control of the CPU to the dummy armfir.elf. EDIT the next day: BTW, besides the motivations of a learning experience, and the "just because we can" motivation, porting Linux to the Prime would give access to a wide range of existing Linux-based userspace programs. That happens on the Nspire as well, even if few people take advantage of it. Many things can be cross-compiled through OpenEmbedded, Buildroot, Yocto and others - and many things are pre-built by other people / infrastructures in the first place, e.g. Debian armel chroots (userspaces from several other distros were successfully tested on Nspire as well). In soft environmental conditions (few calculators are field-hardened devices, and neither the Prime, nor the Nspire, are), calculators can be useful for, among other non-standard purposes: * emulating a HID mouse, a HID keyboard; * providing some form of display accessed through an emulated serial port; * emulating a MSD containing system rescue programs; * implementing one of the first jailbreak procedures for the PS3. The TI-89 Titanium can do all of those, thanks to the "Linky" program by Brandon Wilson. I did use my 89T as mouse + keyboard in the real world, several months after filling in Linky's keyboard mapping code, for the initial setup of an embedded ARM-based board, in the absence of an USB mini-A male <-> USB A female cable. The Prime's CPU (400 MHz ARM9) is far more powerful than a 89T (12-14 MHz 68000), it has immensely more RAM and Flash than a 89T (RAM: 32 MB vs. 256 KB, i.e. 128 times more, and Flash: 256 MB vs. 4 MB, 64 times more), a faster USB controller, etc. Therefore, it could do much better. |
|||
07-13-2014, 01:31 PM
Post: #17
|
|||
|
|||
RE: Third-party firmware PoC...
(07-07-2014 02:02 PM)Claudio L. Wrote:Oops, cyrille then, was going by memory as omnimaga seemed to be down at the time...(07-07-2014 01:01 PM)cutterjohn Wrote: Parisse even deigned to make a few replies, more or less along the lines of I can't tell you much about how the proprietary firmware works, but I can probably drop hints to help hacking, or so I read it. |
|||
07-15-2014, 07:34 AM
(This post was last modified: 07-15-2014 07:38 AM by Kevin Ouellet.)
Post: #18
|
|||
|
|||
RE: Third-party firmware PoC...
(07-13-2014 01:31 PM)cutterjohn Wrote:(07-07-2014 02:02 PM)Claudio L. Wrote: I just read that thread, I didn't see Bernard Parisse making any posts, though. But Cyrille did (unless they secretly are half-brothers, Cyrille's last name is not Parisse). It's funny to see how they refer to Cyrille (quoted from the moderator):Oops, cyrille then, was going by memory as omnimaga seemed to be down at the time... It was probably CloudFlare's fault or an issue on your end, because I checked the IRC chatroom logs and couldn't find any talk of a downtime nor a server reboot on July 7th. I know the site goes down from 1:00 to 1:05 AM GMT-5 every night, though, when the database is backed up. http://chat.eeems.ca:9003/?server=irc.om...007%202014 -Dream of Omnimaga https://dreamofomnimaga.page |
|||
10-26-2016, 06:29 PM
Post: #19
|
|||
|
|||
RE: Third-party firmware PoC...
How would you actually go about this process???
Sorry, I'm a bit of a noob. |
|||
« Next Oldest | Next Newest »
|
User(s) browsing this thread: 1 Guest(s)