I finally got the LCD up on a virtual Air10

[luckyabsoluter]

I just got the LCD running on a virtual STM32-based Air10 device.

This is a really emotional moment. GPT-5.4 is very smart.

This was built with Renode. As the community has found before, there are several things that can stop the program before it really boots. In this kind of situation, it is actually very effective to give the AI both the decompiler and Renode, then have it trace the program counter while pushing execution forward until specific functions are reached.

I told the AI to add virtual hardware where needed, and it worked through a lot of that on its own. It figured out and modeled things like RTC, UART, the home button, power button, encoder, I2C sensors, SDIO, and other pieces needed to keep the firmware moving.

To be honest, I was not very confident for a while because the LCD still was not showing anything. But now the logo finally appeared.

It is still not fully booting, so there are still a lot of things to adjust. But I think it can be shown publicly soon.

If this gets completed, firmware rework is going to become much more convenient.

This discussion is just to share the news before getting into the real technical discussion.

[luckyabsoluter]

To add a few more comments in this context and share some updates:

Because GPT-5.4 is not a codex model, it repeatedly stops working just to report back to me. You can, of course, assign it longer tasks lasting 1 to 4 hours via prompting. Also, the message queue in the VSCode Codex Extension doesn't work properly, making automation quite difficult.

The Codex App is so poorly built and laggy that it's practically unusable.
Using OpenClaw might improve the situation.

GPT-5.4 is now questioning whether Renode's STM32 simulation is actually accurate and is currently analyzing its behavior.

I really hope a better model comes out soon!

[m-kozlowski]

Honestly, as much as I am rooting for this, I still have serious doubts that anything sustainable can be achieved here without a deep understanding of the platform.
There is a ton of stuff to simulate, including things we may not even know exist.

EEPROM is the obvious one. You do not even have to be especially careful with it, because if the firmware finds it empty, it will rebuild it with default values. No serial number, calibration, and so on, but none of that is strictly necessary.
SRAM is less obvious, but still essential.At least that one is easy to spot on the PCB and handled in a standard way.
But the STM8, which the main MCU talks to over its own serial protocol, is already a much tougher problem.
Then there are whatever sensors are involved, analog or digital (I2C), and the firmware will probably start panicking without proper readings from them as well.
And of course there is the external watchdog, which can probably be bypassed easily enough, but still needs to be looked at to understand how.

This is a seriously huge task.