Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Jean-Baptiste Boric

Pages: [1] 2
1
What is your opinion on this change by TI?

We haven't seen them doing something that stupid since the TI signing key legal mess a decade ago. They've truly outdone themselves this time. Throwing their community off a cliff without a warning by removing an advertised feature and deciding that the squeaky toy that is their Python port shall be a replacement of ASM/C, no take-backs.

Vote with your wallet. Don't buy TI. They do not care about anything but money.

From what I could understand, a TI-83 Premium CE python program cannot be larger than 17.7 KB of executable code and there are a few commands that are proprietary rather than actual python.

You'd be lucky to get a Python script bigger than ~5 KiB running. MicroPython scripts on calculators tend to require 2 to 4 times their size in heap in order not to run out of memory.

2
HP Prime / Porting the NumWorks firmware to the HP Prime
« on: June 05, 2018, 12:12:06 pm »
Title says it all. It's still in the early stages, but it does calculate.

https://tiplanet.org/forum/viewtopic.php?t=21540&p=232286
https://github.com/numworks/epsilon/pull/534

I created the ultimate Frankenstein monster... BWAHAHAHAHA! >:D

If people want to try it out, the firmware image is available here: https://tiplanet.org/forum/viewtopic.php?f=102&t=21520&start=20#p232267

3
HP Prime / Re: HP Prime Emulator
« on: May 03, 2018, 04:46:00 pm »


Turns out there's an easy way to trigger the diagnostics tool: replace the FirstRunApp key value inside FIRSTRUN.INI with \\.\DIAGNOSE.ROM. This file is located inside the PRIME_APP.DAT's FAT32 partition, offset 8192 bytes.

Still no response to keyboard input. The firmware doesn't seem to scan the keypad matrix once booted.

4
HP Prime / Re: HP Prime Emulator
« on: May 03, 2018, 03:54:09 pm »
I tried prodding the obvious (GPIO data registers, RSTSTAT) with no results. I'll need to take a closer look at the reset circuit on the hardware and see if I can spot something of interest (once I'm back from vacation 'cause I left the calculator back in my flat). Depending on how HP implemented the C-F-O thing, this may end up being a royal pain to figure out.

5
HP Prime / Re: HP Prime Emulator
« on: May 03, 2018, 01:37:17 pm »
By combining the data part of your image with the firmware bits of an old update file I got something that booted to this:

Code: [Select]
$ dd if=flash_dump of=dat.raw bs=1024 skip=$((256+1024+4096+32768)) seek=$((256+1024+4096+32768))
It's not responding to the keyboard and the clock on the upper right is hung. The firmware doesn't seem to be hung after a quick look with GDB, but obviously something prevents it from fully ticking. The UART has a whole bunch of yaffs logs, I assume the firmware got stuck because homemade images don't have a yaffs filesystem. I do wonder if the "Format Disk C" option in the diagnostic tools would've fixed that.

Do you happen to know on what pin is the reset switch on the prime?

I assume nRESET. I remember being able to boot the calculator straight into recovery mode by holding the SYMB button down and hooking an USB cable without the battery, so I would expect to be able to drop into the diagnostic tools by holding down C-F-O the same way.

With the emulator, I seem to be able to drop into the recovery (which just hangs with a black screen), but not into the diagnostics program. Odd...

6
HP Prime / Re: HP Prime Emulator
« on: May 03, 2018, 11:08:41 am »
I'm not sure doing a low-level emulation of the NT 11002 is the way to go. I believe a high-level emulation of the I2C protocol and not worry about reverse-engineering+emulating a whole MCU would be simpler.

I got a bunch of old firmware update files from educalc.net and I managed to launch them, only to quickly get stuck on a HP logo inside what appears to be PRIME_OS.ROM. Firmwares 20130808 and 20130813 have egregious amounts of logging on the UART which could prove useful (after cleaning up garbage):
Code: [Select]
Run>
Init 320x240
Init 320x240 rVIDCON0=0x5270
320x240 rVIDTCON0=0x110300 rVIDTCON1=0x401100 rVIDTCON2=0x7793f rVIDCON1=0x80
ARMCLK:400000000
HCLK  : 133333333
PCLK  : 66666666
nandid: ec da 10 95 44
InitBfsHeader...
nandid: ec da 10 95 44
block size:0x20000 page size :0x800 Attr:1c03110b NandSize:256(MB)
read header...ok
has BFS header
[00][01]
BFS End.

1ram size :32MB
rBANKCFG:4890d
CodeEntry:0x30000020
CodeLoadeAddress:0x30000000
CodeLoadSize:0x100000
CodeEntry:0x30000020
CodeLoadeAddress:0x30000000
CodeLoadSize:0x100000
MPLL  : 800000000
CLK   : 400000000 (400 MHz)
HCLK  : 133333333
PCLK  : 66666666
ARMCLKDIV  : 1
HCLKDIV  : 1
PCLKDIV  : 1
Nand0ID   = EC DA 10 95 44
Nand0Attr = 51c110b
Nand0Sz   = 256 (MB)
[BFS][0] table items = 2048
[BFS][SetupCorrectTable] wTableItemSum = 2048
Nand1ID   =
Nand1 not exist!
CODE INFORMATION 1
 ARCH: V5J, CPU: 2416
  CMV: 0
CURRENT RUNNING CODE
 ARCH: V5J, CPU: 2416
  CMV: 0
Data0: 00000000 01000000 / 00000000 00400000
 nDataInNand0Size=00000000 00500000
 finding appsdisk(00000000 00500000)...
Data1: 00000000 02000000 / 00000000 02000000
 NandChipNum  =1
 CodeSz       =00100000
 Data0Sz      =00000000 00400000
 ApDskSz      =00000000 02000000
 ApDskInNand0 =00000000 02000000
 TotalSz      =00000000 02500000
Unlcok area: 4a00 ~ 20000
SetVRAMAddress=31e80000
UsbVBusInit
[INFO] makedata version=20090828
[INFO] makedata version=20090828
This system don't support hardware 2D accelerate!!!
kv= 0
[ARCH] id=32450003
[ARCH] name=S3C2450
[ARCH] interface=000000F5
UsbHostVbusInit DEV_CONNECTkv= 0
 startblock: 139
   endblock: 7c7
 startblock: 139
   endblock: 7c7
[NAND Scan]Block size:0x 0 20000
[NAND Scan]Page size:0x 0 800
[NAND Scan]OOB size:0x 40
[NAND Scan]Scan start addr:0x 0 2720000
[NAND Scan]Scan end addr:0x 0 f8e0000
NAND Scan Start!

Firmwares 20130813 onwards show a subliminal message ("Firmware verification in progress. HP Prime will automatically continue when the operation is completed. This may take up to 1 minute").

I used the following to get these images:
Code: [Select]
cat BXCBOOT0.BIN BESTAARM.ROM MASTER.DAT APPSDISK.DAT > dat.raw && dd if=/dev/zero of=dat.raw count=1 bs=1 seek=$((256*1024*1024-1))

7
HP Prime / Re: HP Prime Emulator
« on: May 01, 2018, 04:13:49 am »
Impressive!

I think really old firmwares don't have the slide-to-unlock at first boot. Might be worth trying one out, I vaguely recall the flash having the following layout: BXCBOOT0.BIN (256KiB) | PRIME_OS.ROM (1MiB) | PRIME_MASTER.DAT (4MiB) | PRIME_APP.DAT (32MiB) | data (remainder). Perhaps you can double-check with your existing image if this matches?

Does the diagnostics tool (C-F-O) work? It's likely to be useful for troubleshooting/reverse-engineering, there's test modes for the touch screen.

I'm not tooled for bus sniffing unfortunately, but maybe I can jury-rig something with a Raspberry Pi. Not going to happen right now though, I'm on vacation and I left my equipment behind...

8
HP Prime / Re: HP Prime Emulator
« on: October 29, 2017, 04:52:40 am »
Took a bit longer to set up everything once again than expected, but here it goes :

Code: [Select]
# DRAM Controller
(gdb) x/8xw 0x48000000
0x48000000:     0x0004890d      0x44000050      0x0099003f      0x80000033
0x48000010:     0x00000405      0x00000000      0x00000000      0x00000000
0x48000020:     0x00000000      0x00000000      0x00000000      0x00000000
0x48000030:     0x00000000      0x00000000      0x00000000      0x00000000

# Matrix & EBI
(gdb) x/16xw 0x4E800000
0x4e800000:     0x00000004      0x00000004      0x00000004      0x00000000
0x4e800010:     0x00000004      0x00000004      0x00000004      0x00000000
0x4e800020:     0x00000004      0x00000004      0x00000004      0x00000000
0x4e800030:     0x00000004      0x00000004      0x00000004      0x00000000

# Memory Controllers ( SSMC )
(gdb) x/64xw 0x4F000000
0x4f000000:     0x0000000f      0x0000001f      0x0000001f      0x00000002
0x4f000010:     0x00000002      0x00303000      0x00000000      0x0000001f
0x4f000020:     0x0000000f      0x0000001f      0x0000001f      0x00000002
0x4f000030:     0x00000002      0x00303000      0x00000000      0x0000001f
(gdb) x/8xw 0x4F000100
0x4f000100:     0x00000000      0x0000001f      0x0000001f      0x0000001f
0x4f000110:     0x0000001f      0x0000001f      0x0000001f      0x0000001f
(gdb) x/8xw 0x4F000200
0x4f000200:     0x00000000      0x00000003      0x00000000      0x0000000a
0x4f000210:     0x00000000      0x00000000      0x00000000      0x00000000

# Interrupt controller
(gdb) x/16xw 0x4A000000
0x4a000000:     0x00004004      0x00000000      0xffffffff      0x00000000
0x4a000010:     0x00000000      0x00000000      0x00010003      0x1fffffff
0x4a000020:     0x00000000      0x00000000      0x00000000      0x00000000
0x4a000030:     0x00000000      0x0000007f      0xdeadcafe      0xdeadcafe

# System controller
(gdb) x/16xw 0x4C000000
0x4c000000:     0x0000ffff      0x0000ffff      0x00008000      0xdeaddead
0x4c000010:     0x80640061      0xdeaddead      0x01200102      0x00000000
0x4c000020:     0x00000118      0x0000022d      0x00000000      0x00000000
0x4c000030:     0xffffffff      0xffffffbf      0xffff9fff      0xdeaddead

# I/O ports
(gdb) x/72xw 0x56000000
0x56000000:     0x005e0000      0x00007000      0x00000000      0x00000000
0x56000010:     0x00141016      0x000003ea      0x00000950      0x00000000
0x56000020:     0xaaaa56aa      0x000000b0      0x00000000      0x00000000
0x56000030:     0xaaaa5555      0x00000080      0x00000000      0x00000000
0x56000040:     0xa0000000      0x0000c000      0x05555555      0x00000000
0x56000050:     0x000061a1      0x0000007d      0x00000404      0x00000000
0x56000060:     0x00000000      0x0000ff00      0x00005555      0x00000000
0x56000070:     0x1400150a      0x00000062      0x01554050      0x00000000
0x56000080:     0xd0000020      0x00000000      0x00000000      0x00000000
0x56000090:     0x00000000      0x00000000      0x00000000      0x00000000
0x560000a0:     0x00000000      0x00fffff0      0x00000040      0x0000000f
0x560000b0:     0x32450003      0x00000000      0x00000000      0x00000000
0x560000c0:     0x2aaaaaaa      0x0aaaaaaa      0x0aa8aaaa      0x00000000
0x560000d0:     0x00000000      0x00000000      0x55555555      0x00000000
0x560000e0:     0xaaaaaaaa      0x00000000      0x55555555      0x00000000
0x560000f0:     0x04050055      0x00007cf0      0x00050055      0x00000000
0x56000100:     0x00000008      0x00000003      0x00000000      0x00000000
0x56000110:     0x000002aa      0x00411540      0x05451500      0x00ff0000

9
HP Prime / Re: HP Prime Emulator
« on: October 27, 2017, 11:50:06 am »
I checked and I have everything at hand in my flat. I'll perform the hex dumps tomorrow.

10
HP Prime / Re: HP Prime Emulator
« on: October 26, 2017, 05:38:51 pm »
It's been way too long (NumWorks is kinda distracting me these days), but there should be 32 MiB at 0x30000000 and 64 KiB at 0x0. The DRAM controller can map up to 128 MiB of memory.

Not sure why the official firmware would want to poke beyond 0x32000000. It could be memory prodding/detection (unlikely), GPIO/hardware registers not having the right values or plain old sloppiness. I can poke memory around with the Rip'Em GDB stub over serial if you need.

11
Currently no, since Rip'Em can't access the NAND so it's limited by the 1 MiB that BXCBOOT0.BIN loads.

However, with the recently-created, QEMU-based emulator (https://github.com/Gigi1237/qemu) I can now rewrite Rip'Em to include such functionality. If you can use the emulator, you can use its -kernel option to load large ELF files (limited by RAM capacity).

12
HP Prime / Re: HP Prime Emulator
« on: August 19, 2017, 10:40:45 am »
Rip'Em is a really, really simple piece of code, so it's fairly easy to make it run. It doesn't even uses interrupts or timers, it has effectively the equivalent complexity of a "Hello World!"-class program.

The official firmware is infinitely more sophisticated than that. There's much, much more going on inside a HP Prime than just a ARM9 core and a bunch of RAM.

13
HP Prime / Re: HP Prime Emulator
« on: August 19, 2017, 08:41:49 am »
So I took a quick look at your branch and I've already submitted a pull request (mostly just cleanups to make it work on my Linux box).

Soon I'll finally be able to work on Rip'Em without losing my sanity in the process. Yay! :w00t:

14
HP Prime / Re: HP Prime Emulator
« on: August 18, 2017, 01:18:43 pm »
Here's the PRIME_OS.ROM of Rip'Em and the ELF programs, for testing on your side.

15
HP Prime / Re: HP Prime Emulator
« on: August 18, 2017, 04:06:14 am »
Thanks for giving the link to the UART log, it was helpful. The output qemu is giving me is slightly different: https://gist.github.com/Gigi1237/0a5c3bd41f53bea14434c6673e6f0cbf#file-gistfile1-txt. Mainly becaus it spams me with "B"s right after printing start. I haven't figured out why yet though. Probably some mistake in the UART implementation.

Wow, you've reached PRIME_OS.ROM, that's impressive! That means the first stage of the bootloader actually worked.

Right now I'm a bit stuck with it, don't really know what exactly to do next to get it working. I'm especially in a hard spot because I don't have acess to my IDA Pro databases of both the OS and the bootloader which would help a ton with debugging at this stage.

I would try to make Rip'Em work. Since it's vastly simpler and the source code is available (unlike the official firmware), figuring out why stuff is not working should be much easier. Next goal would be the diagnostics utility.

Today is the last day of my internship, so I'll be able to take a closer look at your QEMU tree real soonTM.

Pages: [1] 2