Hi Dmitry:
About question "In my previous e-mail I requested you to enumerate changes that
are made to the driver, compared to the previous version(s). There were also a
few questions that I did not get answer for."
In order to improve flash read/write security of boot loader. We increase
handshake flow and command sequence complexity. Our previous flash write
functions are single side action. New version we increase more handshake flow
to check data accuracy. Firmware update flow increases as below:
1.Check firmware file size, if file size is null, return fail.
2.Check touch MCU run on main firmware or boot loader. Both cases have
different return values. In case of flash write function, if touch MCU work on
main code, touch driver need issue enter boot loader command to touch MCU and
wait for MCU boot mode ready.
3.Turn off touch MCU watchdog function to prevent interference.
4.Check boot loader write state path ready.
5.Send boot mode trigger command to unlock flash-write-protection.
6.Execute page write command. Each write command will wait touch MCU
acknowledge and then execute next step.
7.Leave boot loader to check firmware work.
8.Raydium touch driver check touch MCU work on main firmware or not. If
touch MCU work on main firmware and return correct acknowledge to kernel, this
means flash write command success.
9.Write checksum information to flash.
Every touch driver flash write command accompany write command, acknowledge
byte and wait for acknowledge command. Different sequences have different write
commands and different state to return ack.
Previous version as below :
1.Get firmware data
2.Force jump to boot loader by soft reset command
3.Wait for boot loader acknowledge
4.Flash page write data directly
5.Force jump to main firmware if page write data finish.
New flow increase more acknowledges for each I2C command to make sure boot
loader got the message and finish the actions. After finish flash write data,
new flow will le touch MCU jump to main firmware and check main code work well.
Then write the total checksum to flash and check the consistence of flash code
in every boot time.
New flash write flow is very different form previous version, but more safe.
The difference is big. Sorry make you confuse.
The question "I still can't figure out the logic in read/write mesage handling.
Here we see that device is supposedly reporting data_bank_addr as LE integer,
but query_bank_info is returned in native CPU endianness. With fastboot command
we assume that we are dealing with BE-encoded data and convert it to
CPU-endianness before using it.
However in raydium_i2c_read_message() we convert from CPU endianness to BE and
this comfuses me (does the device really return data in one endianness but
accepts in another endianness?"
Raydium MCU support direct access mode by I2C bus to access register or
physical buffer directly. In this direct access mode, our touch MCU use BE
integer by using commands of raydium_i2c_read_message/
raydium_i2c_send_message. Otherwise, raydum I2C normal mode use LE integer. By
the way, the command buffer of soft_rst_cmd[] is upside down.
The question "By the way, why do you have raydium_i2c_read_message() handle
reads above MAX_PKG_SIZE? There are no callers that want it."
Generally, I2C bus has maximum packet size but total touch report points maybe
exceed this size. Unfortunately my experimental chromebook device exceed this
size. So that I’ll split this read command two or more to make sure all data
are read.
