10:43 <f_> I'm back :P

10:43 <f_> Today, let's figure out why it resets after "INFO: BL2: Loading image id 3"

10:46 <f_> Source code exactly the same as https://git.vitali64.duckdns.org/misc/trustedfirmware-a.git/log/?h=wip/gxbb

10:46 <f_> Made no real changes whatsoever.

12:40 <rockosov> Hello! I apologize for the seemingly simple question, but may I ask what your goal is? Even if your ATF branch is successfully booted, it may not provide all the necessary Amlogic components for practical production use. I do not wish to belittle your contribution, but I am uncertain of how it will aid in the open source usage of ATF Amlogic for release devices. My team and I have conducted

12:40 <rockosov> experiments to replicate ATF Amlogic features from binary to ATF source code, and it is an enormous undertaking if you intend to complete it entirely.

13:13 <narmstrong> rockosov: some people (a lot in fact) want to have a fully open sw chain, even if less features are supported, and well amlogic is one of the last platform with no open-source full TF-A support so it's good if something happens if if it will be never production ready

13:19 <rockosov> narmstrong: I understand, thank you for clarifying! Then we will try to help you to moving forward with this activity. However, I must admit that I remain quite skeptical regarding the potential for a fully successful outcome... Amlogic has NUMEROUS custom features, ranging from customized handling of JTAG/efuse to secure videobuf management, which may pose significant challenges to our

13:19 <rockosov> efforts...

13:24 <narmstrong> rockosov: yep I totally understand your needs, but it's a balance between openness and features... other platforms actually provide security features in open-source TF-A so it's more a political issue than a technical issue

13:27 <narmstrong> rockosov: but we won't drop linux & u-boot support for vendor fip, don't worry :-)

13:28 <rockosov> narmstrong: Agree.. At any rate, I see that any contribution towards supporting ATF Amlogic is valuable. This is certainly good news!

13:29 <rockosov> narmstrong: :-)

14:34 <f_> Hi rockosov!

14:35 <f_> You may remember (or not) that Amlogic originally used a libre BL2.

14:35 <f_> Here it is -> https://github.com/hardkernel/u-boot/tree/be63a06fa3d50dd2410e2e722d1f8bafe7370abd/arch/arm/cpu/armv8/common/firmware

14:35 <f_> I made a mirror (for archiving purposes) here, too -> https://git.vitali64.duckdns.org/archive/amlogic-bl2.git/

14:36 <f_> But then, there's a commit "BL2 closed-source" and it's removed from the tree, and this is when acs.bin was born.

14:37 <f_> chewitt told me that recently (https://libera.irclog.whitequark.org/linux-amlogic/2023-05-02), and as expected it's just TF-A with Amlogic mods.

14:38 <f_> rockosov: "Then we will try to help you to moving forward with this activity" You and your team are very much welcome to do so!

14:39 <f_> The only thing I'm interested in, for now, is getting it to a point where linux boots successfully.

14:40 <f_> All other non-essential features can be worked on later.

14:41 <f_> So basically, getting it to load U-Boot and linux with working UART is the main goal here, with fully libre code.

14:53 <f_> So yeah, everyone is welcome to make that happen!

15:29 <f_> I'm 100% sure it fails here -> https://git.vitali64.duckdns.org/misc/trustedfirmware-a.git/tree/common/bl_common.c#n86

15:29 <f_> What's weird about it is that it fails silently..

15:29 <f_> no warnings, nothing....

17:10 <f_> Will have to go in a bit.

20:13 <minute> narmstrong: was playing a bit with a311d dsi again, unsuccessfully. i wonder if i have to calculate clk_lp2hs, data_lp2hs and friends correctly?

20:13 <minute> (as these are currently hard-coded)

20:14 <narmstrong> minute: did it change something or it was the same flickering ?

20:14 <minute> narmstrong: the flickering goes away over time, so it's hard to tell

20:15 <narmstrong> minute: the values are specific or vendors and I have no idea how they should be calculated for amlogic

20:15 <minute> hmm, i see. there's no downstream code where this could be gleaned?

20:16 <narmstrong> minute: yes khadas has a tree but it’s hard to figure out any info

20:16 <minute> narmstrong: do you happen to have a link to their code?

20:16 <minute> narmstrong: also, can i just adjust the esc_clk_rate in dw_mipi_dsi_get_esc_clk_rate or do i have to also do that elsewhere?

20:18 <narmstrong> drivers/amlogic/media/vout/lcd/lcd_tablet/mipi_dsi_util.c

20:18 <minute> thx, interesting, that's also part of android

20:18 <narmstrong> The esc-clk-rate seems to be fixed on the platform, this is why I set it like that

20:20 <minute> ah, thanks

20:21 <narmstrong> Hmm

20:21 <narmstrong> If you find something… tell me

20:33 <minute> haha these calculations are really something

20:33 <minute> i mean these https://android.googlesource.com/kernel/arm64/+/f5269100977385d1fd4a5ef68e49631892cf4fe4/drivers/amlogic/media/vout/lcd/lcd_tablet/mipi_dsi_util.c#1567

20:35 <minute> ah, u-boot has a slightly more compact version https://github.com/endlessm/u-boot-meson/blob/master/arch/arm/cpu/aml_meson/m8/lcd/mipi_dsi_util.c#L559

20:44 <minute> ah sorry, these are used in dphy. alright

20:47 <minute> ah, but for 1920 we should be using those magic numbers for state_change == 1, not 2, right

20:52 <minute> narmstrong: OMG it works

20:53 <minute> narmstrong: the fix is to use these timings for 1920x1080: timing->clk_lp2hs = 23; timing->clk_hs2lp = 38; timing->data_lp2hs = 15; timing->data_hs2lp = 9;

20:53 <minute> i gleaned this from here and below https://android.googlesource.com/kernel/arm64/+/f5269100977385d1fd4a5ef68e49631892cf4fe4/drivers/amlogic/media/vout/lcd/lcd_tablet/mipi_dsi_util.c#773

20:56 <minute> narmstrong: pic https://mastodon.social/@mntmn/110374692787267453