07:11 <narmstrong> gbisson: the bl32 and the TA apps should work, not sure if the corresponding HALs would still work on aosp

07:52 <gbisson> narmstrong: yes exactly, that's why I was wondering if we could use the standard apps from AOSP instead not to deal with outdated HAL

08:45 <gbisson> narmstrong: just to be sure: I've flashed the EVK bootloader onto my platform and it bootloops as the EVK doesn't include the proper DDR timings in ACS, the HW team forgot to expose EMMC_D5 to force USB recovery, is there any other trick to recover from that state? Otherwise I'll have the eMMC replaced

08:49 <narmstrong> gbisson: you can try the hdmi dongle trick

09:00 <narmstrong> https://github.com/superna9999/linux/wiki/Amlogic-HDMI-Boot-Dongle

09:11 <gbisson> narmstrong: Nice! Thanks!

09:29 <gbisson> narmstrong: do you know if this works with most emulator? or have you seen some emulators where the flash is locked?

09:31 <narmstrong> gbisson: yes i had some emulator which eeprom only supported the 0x50 i2c address

09:32 <narmstrong> The ones I buy on aliexpress works fine

09:32 <gbisson> narmstrong: thanks, then I'm gonna buy a few different ones, I'm gonna try Amazon as I'd like to try it today ;)

09:32 <narmstrong> I need to buy some again BTW

09:32 <gbisson> yup otherwise I would have bought it from you directly ;)

09:32 <narmstrong> If you have some working tell me so I update the wiki with the refs

09:33 <gbisson> sure

09:33 <gbisson> BTW you link is dead (the aliexpress one)

09:33 <narmstrong> It’s expected, I’ll update it with the last one I used

09:36 <gbisson> ok I bought 3 different brands out of Amazon, hopefully one will work

09:37 <gbisson> is the A1 pin the write protect one? That's why we need to modify it?

09:38 <narmstrong> Nop it’s the address bit 1

09:38 <narmstrong> To form 0x52 instead of 0x50

09:39 <gbisson> oh I see, thanks

09:39 <gbisson> Gonna be fun to try that out, and this check happens in the bootrom before trying the DDR training right?

09:43 <gbisson> BTW, quick feedback on MIPI, we definitely need to change VIU_OSD_HOLD_FIFO_LINES to 24 to avoid the shaking issue

09:44 <gbisson> (I saw that recommendation earlier in the channel)

09:58 <narmstrong> gbisson: yes the bootrom reads on the HDMI DDC pins, even if no HDMI port before loading anything

09:58 <gbisson> perfect, thanks again!

10:08 <narmstrong> my last emulator command was https://fr.aliexpress.com/item/4000494867545.html

10:29 <gbisson> ok noted, hopefully the ones from amazon can easily be opened and contain an eeprom whose address can be changed (that's a lot of if but I get to know tonight)

13:08 <tdebrouw> narmstrong: I haven't been able to test your new g12 mipi implementation yet. Currently busy with something else

13:09 <tdebrouw> narmstrong: but I have seen (with the older code) a shaking issue every 10 - 20 minutes, even with VIU_OSD_HOLD_FIFO_LINES set to 24

13:09 <tdebrouw> of course, it could also be something else

13:11 <tdebrouw> I just wanted to note that the issue isn't entirely solved on my side yet.

13:11 <tdebrouw> but still, thanks for all the help/code so far.

13:33 <gbisson> tdebrouw: on my end the shake is gone, but the timings are tricky to get correctly as they don't match the docs of the display (FYI)

13:35 <gbisson> narmstrong: I think I know why you had to re-write the B character, it's the CRC byte which should be 0x64 ('d') for an empty block

13:36 <gbisson> narmstrong: I'm trying to use my TC358743 HDMI input capture device and upload a custom EDID to it, it changed the 'B' into 'd' to fix the CRC ;)

13:55 <narmstrong> tdebrouw: gbisson: lower should probably be fine, anyway I’ll cleanup everything and make it upstreamable so we can solve the remaining issues

13:55 <narmstrong> gbisson: weird it was with the first dongles, now the last byte is written correctly

13:55 <narmstrong> Maybe an issue with the at24 kernel driver at the time

13:58 <gbisson> well actually it shouldn't have happened for you, in my case it's because it goes through the kernel to write the EEPROM knowing that it's an EDID and therefore checking the CRC

13:59 <gbisson> in your case it should be a standard EEPROM with data written to it, anyway, I was just surprised to see the last bit being overwritten but then I saw a kernel trace telling me about the CRC

15:34 <gbisson> if anyone tries to do the HDMI recovery with a TC358743, the chip has a register to set the "EEPROM" address, but changing this register doesn't change anything, it always shows @0x50, so I'm still desperately waiting for those Amazon dongles

15:53 <narmstrong> the soc has a slave i2c HW, and is exposed on the VIm3 header, so soldered to an connector and 5v pullup it should be doable to simulate an eeprom on addr 0x52

15:53 <narmstrong> maybe I'll write the i2c slave driver for fun :-p

15:56 <gbisson> Yup that could be an option, I most have imx platforms and last time I tried slave I2C (years ago) it was a nightmare

15:57 <gbisson> Or an RPi could do the trick I guess

16:07 <gbisson> BTW, how did you find that info about the bootrom? ;)

16:27 <narmstrong> gbisson: it was used to hack a Fire TV dongle, they forgot to enable password for USB boot... and they used this tweak to force USB boot

16:41 <gbisson> narmstrong: nice, thanks!

22:29 <gbisson> narmstrong: thanks so so so much! It worked!

22:30 <gbisson> out of the 3 references I bought from Amazon, the first one (Qianrenon) doesn't have an EEPROM whose address can be changed

22:30 <gbisson> but the other two are identical (ADWITS & eFUTURA) with a standard 24c02 EEPROM

22:31 <gbisson> I reworked one of them, updated the EEPROM and it worked right away, nice tutorial

22:32 <gbisson> FYI in order to lift the pin I removed the entire thing (was easier as I had no needle around)