OneROM

[jxx]

Glad it made it over intact.

Only just got the circuit boards to mod an 808 today, but i changed direction after ordering them, waiting on a much smaller bdlls inverter circuit board now.

I've managed to hack together BPLZ9214.BIN into the onerom alpha firmware, tunerpro dumps and verifies the rom contents. Gq-4x also verifies the rom correctly.
Yet to be able to upload and edit via tunerpro, this manually reverse engineering the firmware to get it to work is doing my head in.

Have not tested, possibly really broken, CRASHES the onerom when you try to upload in tunerpro.
Will try to get a car running, atleast a dead starter motor in the vr is easier to fix than the vn's with dead fuel pumps i have here.

***REMOVED***OneRom-ALPHA.BPLZ9214.zip


EDIT.

Further testing, gets partway thru an upload and then crashes the onerom.
But it will upload, verify, read a 64k file that is filled with FF. Changed address 0xFFFF to AA to make sure it wasn't looping at 32k, can write, read and verify with that as well.
As soon as i try a 64k VR bin file (tried quite a few) it crashes.
Seems there is a write buffer in the ostrich emulation that can't keep up with the larger file size.
Narrowed it down to exceeding 8k thru trial and error, maybe a buffer or somehow this firmware doesn't handle bank switching correctly.

EDIT 2.

Further testing.... I've tried overclocking/underclocking the rp2350, no change in being able to upload from Tunerpro after editing.
Probably going to be easier to start from scratch and build a new firmware instead of trying to hack the source-unavailable compiled binary, at least proof of concept is there and kinda sorta works.

Honda tuning suite works, not familiar with the software to know what it does different.
CROME has similar problems to Tunerpro, crashes when trying to upload.

The firmware as far as I can tell should run on a Pico 2 to test Tunerpro and Ostrich emulation (I don't have 1 to test with if someone could confirm).
Seems the Alpha creator is not going to be working on it anymore and leaving it as is, which is a shame.

Here's some bin/uf2 images stripped down to blank 27C512 for the rp2350/rp2354 onerom firmware.

***REMOVED***OneRom-Alpha-OstrichV20.9-27C512.zip
***REMOVED***OneRom-OSTRICH-27C256-FFFF.zip



The flash layout is as follows, with all addresses relative to the flash base address, RP2350 (0x10000000):
https://github.com/piersfinlayson/one-r ... H-USAGE.md

+-------------------------+ 0x00000000
| One ROM Firmware |
+-------------------------+ 0x0000C000
| One ROM Metadata |
+-------------------------+ 0x00010000
| ROM Images |
+-------------------------+ 16/64KB boundary

Moates Ostrich Emu
0x00010000 - 0x0001FFFF

ECU bin file
0x00020000 - 0x0002FFFF

No, you can't just paste a .bin file to this location, it gets mangled by the onerom software/firmware.


(To make it simple i've written it so don't have to copy and paste from different addresses)
27C256 32kb instructions

Use the onerom cli make a bin.

Code: Select all

onerom.exe firmware build --board=fire-28-a --slot file=<ECU.BIN>,type=27c256 --slot file=<ECU.BIN>,type=27c256

Firmware written to onerom_fire-28-a_v0.6.13.bin

Copy the "onerom_fire-28-a_v0.6.13.bin" to picotool directory and rename to "unpatched.bin"
Copy "OneRom-Alpha-OstrichV20.9-27C256.bin" to picotool directory and rename to "patched.bin".

Copy 0x20000 - 0x2FFFF from "unpatched.bin" and write over "patched.bin" at the same address.

Start onerom in BOOTSEL mode.
Upload patched.bin

Code: Select all

picotool.exe load patched.bin -t bin

Reboot the onerom.

Code: Select all

onerom.exe control reboot

If it was successful the led should light at full brightness and able to connect with Tunerpro.




Obviously all this can be skipped and just program a bin with the onerom tools to emulate an eprom.
Standard onerom tools can't just change parts of the rom image and upload, the entire thing needs to be reprogrammed.
I think it's in the future for Piers to change this but it's not implemented yet.

[jxx]

Starting from scratch was the right call.

Working ostrich-compatible protocol serial emulation device on the OnerROM serving as a 27C256 Eprom.
Tunerpro RT 5 connects, uploads, downloads, verifies.
Reads back in the GQ-4X perfectly.

When I posted this I hadn't tested in a vehicle, that has now been done.
Tested a work in progress 27C512 variant in a VR V6 auto pcm, Engine fired up after writing the bin to the onerom with tunerpro.
Working on implementing an ALDL Uart passthru, but getting the emulator working was the main hurdle.


Not sure if it's an Ostrich or an Emu.

***REMOVED***OneROM_27C256_EMU.zip

See Post below for releases.
Will Compact Releases with notes into a single post

OneROM_Memcal_808.png

In the future hope to port this to the Onerom Fire 32 variant to replace VS/VT 27C010.
There's a fair bit of headroom for speed if needed, currently the RP2350 is clocked at 150mhz, in theory it can be clocked upto 500mhz but will probably need a heatsink at those speeds and I doubt it'd like the Aussie summers hidden in a metal can inside a car.
My preference is the OneROM using a RP2350 with external flash (atleast can replace that if it eventually dies) and not the RP2354 with internal flash.... although hitting 100K write cycles would take a while.


All older files i've uploaded in this thread are pretty much useless and have been removed instead of wasting space.
Enough information has been left in the thread to replicate what was tried and failed, dead end trying to patch that firmware.

[antus]

Not sure if it's an Ostrich or an Emu.

Well, the ostrich is an emu, so both?

But be careful with branding. When I made antusprom originally I mentioned autoprom and got a warning for trademark from Moates. No bad blood, not a problem, he was really cool, just wanted me to use something else which I did.

[jxx]

Not sure if it's an Ostrich or an Emu.

Well, the ostrich is an emu, so both?

Yeah, I almost went with Eastern Rosella but it just didn't fit, that's why i'm only referring to it as an "ostrich-compatible protocol serial emulation device", I don't want any bad blood or hassles.
Sorry for all the edits and changes to that last post, didn't pick the bug up quick enough so tried to minimalise damage as soon as I discovered it.

[antus]

Eastern Rosella, that's gold!

[vlad01]

Isn't our big bird the cassowary? sticking to the theme and all.

[antus]

That works!

I just came back to this thread and realised that an emu is one of those big Aussie birds, I totally heard the word em-you (not eem-you) in my head and just went straight to emulator without even realising the joke!

[jxx]

I'm not feeling to good about emulating a cassowary... those things can kill.

[jxx]

Ostrich-compatible protocol serial emulation device and OnerROM Fire 28, 27C256 & 27C512 Eprom Emulator.

As i've linked to this post from the first post i'll continue to update the available images below.


Changes:
REV D to REV F1:
Used a flash auto-commit with 1.5 second delay after comms were idle before the uploaded data copied from SRAM to Flash, wrote entire 32K/64K.
May have cause a stall or CEL if the ECU was reading the ROM in the few hundred milli seconds when the flash was being updated, possibly hanging CPU and dropping USB bytes.

REV G:
Changed to sector-staged incremental writes, should no longer suffer issues noted for REV F1

REV H:
This is probably the biggest major revision for a while, unless there are bugs reported that need fixing.
3 Changes for the upload, reliability, speed changes/optimisations, USB reliabilty and reduce chances of CPU hanging during uploads.

1. Per-byte debounce touch
Now called at the start of every write and on every write byte. This re-arms the idle timer continuously during an upload, so the
flash commit cannot fire mid-upload - only fires after the host has been fully idle for the debounce window.
This directly closes the race that was dropping USB bytes.

2. Write-state guard
Now refuses to commit changes while the parser is in WRITE_DATA or WRITE_PARAMS. Protection backup to 1.

3. Compare-skip unchanged blocks
Before erasing+programming each 4KB block, it memcmps the RAM block against the memory-mapped flash block. If identical, it skips the
erase+program entirely - no interrupts-off window for that block. A typical tune edit now commits only the minimal changed blocks instead of all,
speeds up the commit and drastically reduces the number of interrupts-off windows that could collide with an upload and reduces flash wear.



Bank switching is disabled, planning to re-enable this in a future or seperate revision.
Just isn't feasible to have that option enabled while i'm still working on comms as the bank switching would use the same pins.


Releases
Tunerpro first com port.
ECU Data second com port.

I have not tested any of the comms in hardware, supplied as is, where is.
Unfortunately I don't have vehicles to check the normal mode passthru, If you do can you please confirm if it's working or not.
ALDL, currently testing, unfortunately it's taking longer to get working than I expected.
Bugs found or suggestions let me know.


NORM: 115200 8N1 completely UNTESTED with ECU, passes loopback echo in testing. Serial Will not work in Holdens.
USB-to-serial bridge passthru.

32K 27C256

OneROM_27C256_EMU-REV_H-uart_NORM.zip

64K 27C512

OneROM_27C512_EMU-REV_H-uart_NORM.zip

DIS: 2nd COM Port disabled, self explanatory

32K 27C256

OneROM_27C256_EMU-REV_H-uart_DIS.zip

64K 27C512

OneROM_27C512_EMU-REV_H-uart_DIS.zip

ALDL: 8192 baud 8N1. Straight byte passthru at ALDL baud with no inversion EXPERIMENTAL.

32K 27C256

OneROM_27C256_EMU-REV_F1+G-uart_ALDL.zip

Work in progress, I have not been successful to get ECU data working.
It does pass a physical jumper across the pins on the onerom with a loopback test.
Uploaded for testing purposes.
If you get some life out of it let me know:
What needs changing
What hardware you are using to link the ECU and OneROM
Which lines need inverting (TX, RX or Both for your purposes) and I can build a suitable image to try.

So far first ECU i was testing on turned out to have dead comms.
Have not been successful with the 2nd ECU and its origins unknown.





Same pinouts as in the earlier post.
WARNING The pins cannot be connected to standard 5V comms, connect via a 5V <-> 3.3V level shifter, suitable resistor voltage divider (minimum 10K ohm resistors), but a schmitt trigger circuit would be the best option.
Pins 40 & 41 on the RP2350/RP2354 are used for this and are NOT 5V tolerant pins.
All 5V tolerant gpio are in use for the Eprom pins.

Pin 1 OneROM TX <-> ECU RX
Pin 3 OneROM RX <-> ECU TX

TXRX_Pinout_Small.png

All the legal stuff:
Any OneROM code used in this binary please refer to this licence.
https://github.com/piersfinlayson/one-r ... LICENSE.md

All OneROM information and code used in this project (excluding the ostrich-compatible serial device plugin) can be found here
https://github.com/piersfinlayson/one-rom

The ostrich-compatible serial device plugin included in these files is released under the MIT licence.

MIT Licence

Copyright 2026 TXRX

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the “Software”), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

[jxx]

EDIT:
(Due to attachment limitations I can't attach this to the above post)

REV G.2_beta


Dropping this path for future updates for the time being.
Protocol changes caused issues with the exisitng protocol and tunerpro reliability.
It also broke the 27C512 version.
There are other people working on honda compatible firmware.
As much as I'd like to be fully compatible with other software platforms, it just isn't playing nice with my existing code.


Protocol to connect to honda tuning suite correctly which doesn't work in earlier versions.
Only 32Kb variant at this time, still patching some bugs.

32Kb 27C256
***REMOVED****OneROM_27C256_EMU-REV_G.2_BETA-uart_NORM.zip
Dropped due to data corruption during upload and inconsistent writes.








***Original POST Below***
So down the rabbit hole trying to get ALDL working over the 2nd com port.

Well that's done my head in for the evening, tried bi directional 5v-3.3v level shifters, voltage dividers, single resistors, resistors and diodes.... why did GM have to be different.
Occasionally get a chunk of data but getting it to read reliably as a 2 wire protocol just doesn't want to happen.
Might just have to go back to plan A and drop the max232 circuit in to do the heavy lifting and just tap off that.