00:14 <khilman> repk: oops, I spoke to soon (booted the wrong SD card)

00:15 <khilman> I'm actually getting this when booting the ATF + uboot I just built:

00:15 <khilman> https://www.irccloud.com/pastebin/SoWNFjRG/

00:17 <khilman> https://github.com/ARM-software/arm-trusted-firmware/blob/master/plat/meson/gxl/gxl_bl31_setup.c#L77

00:18 <khilman> I added some more debug and arg1=0

00:20 <khilman> I built ATF with DEBUG=1 and in gxlimg, I built `make image` using DEBUG=1 also

06:08 <repk> khilman: hm weird. Do you use an old bl2 by any chance ?

06:12 <repk> or even a bl2 for gxbb

08:15 <kszaq> xdarklight: Can you tell me how usable is https://github.com/xdarklight/linux/tree/meson-mx-integration-5.3-20190512 ? Amazing work BTW on meson8 upstreaming!

10:11 <mjourdan> xdarklight: thanks! Very good news indeed.

14:10 <khilman> repk: afaict, the bl2 is coming from the tarball that is fetched from baylibre github

14:17 <repk> khilman: are you using aml_encrypt_gxl to create the FIP or gxlimg ?

14:29 <khilman> gxlimg

14:29 <khilman> I'm following the gxlimg docs and doing `make image`

14:30 <khilman> which fetches the tarball from github

14:30 <khilman> I then copy that build/fip dir, replace the bl32.img with the one I built myself, and then re-run `make image` with FIP= pointing to my copy of the build/fip dir

14:40 <repk> ok, good. I'll retest that in a couple of hour.

14:41 <repk> bl32 ? you meant bl31 right ?

15:18 <khilman> oops, yes. I copied bl31.img from ATF build into the FIP= dir

16:15 <xdarklight> kszaq: (in case you're reading the IRC logs from whitelogger) thank you! :) my tree "works for me", it may or may not contain hacks and/or code which will never be submitted upstream. if you have a specific question then let me know and I'll try to give a more precise answer. general rule of thumb: Kevin's "integ" branches will not have any broken patches in it because we try not to submit broken patches to Kevin (https://git.kernel.

16:15 <xdarklight> org/pub/scm/linux/kernel/git/khilman/linux-amlogic.git/) ;)

16:15 <xdarklight> that link was cut in half... here we go again: https://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-amlogic.git/

19:23 <repk> khilman: ok good news is that I have reproduced your problem. The bl2 I used was for "BL2 Built : 11:58:42, May 27 2017" and the one producing an error is "BL2 Built : 16:20:27, Apr 19 2018". They must have changed the way they pass arguments

19:24 <repk> what is weird is that ldevulder tried that recently (way more recently than Apr 19 2018) and it worked IIRC.

19:25 <ldevulder> repk, I don't remember exactly the BL2 version, I'm checking

19:26 <repk> I think I know what happened

19:26 <ldevulder> repk, I tested on khadas vim1 and vim2, both with the same BL2 and it's this one: "BL2 Built : 20:32:17, Sep 8 2017."

19:26 <ldevulder> so an old one

19:26 <repk> ok

19:27 <repk> I think it is a bl2 built in debug

19:27 <ldevulder> I remember to have tried a more recent BL2 but I had issue (with amlogic ATF, not tested with yours)

19:29 <repk> khilman: so yes if you can try to build bl31 with DEBUG=0 that should do it. At least it does for me

19:30 <repk> I will send a patch to remove the assert as we do not control how bl2 has been built

19:36 <xdarklight> that seems like a small gift for reverse engineering BL2 ;)

19:38 <ldevulder> repk, khilman, where did you find the BL2 from Apr 2018? I would give it a try on vim1/2 :-)

19:39 <ldevulder> I only see an old one on the baylibre github...

19:49 <repk> https://github.com/BayLibre/u-boot/releases/download/v2017.11-libretech-cc/libretech-cc_fip_20180418.tar.gz

19:50 <repk> oh no unfortunately this one breaks secondary CPU boot

20:20 <ldevulder> repk, thx

20:20 <ldevulder> this BL2 seems to be on vim2 but not on vim1, as there is no support for ddr3 @ 768Mhz in it, only 912Mhz

21:08 <repk> ah no silly me booting secondary CPU is still fine with this "new" BL2/BL30.

21:09 <repk> So yes building with DEBUG=0 or removing the assert should do the trick

21:33 <khilman> repk: DEBUG=0 for both ATF and the gxlimg `make image` step?

21:49 <khilman> repk: DEBUG=0 worked, thanks. But I think the better fix (as you suggested) is just to remove that assert, so I've tried that and submitted a PR: https://github.com/ARM-software/arm-trusted-firmware/pull/1929

21:53 <ldevulder> hmmm it seems that since kernel 5.0 mmc driver is not working anymore on khadas-vim... I'm not able to access emmc since (works well on a 4.20 kernel), maybe related to mmc changes I saw on the ML

21:54 <ldevulder> I saw some changes on vim2 but not on vim, I will try some changes in the DT to see if I can boot

21:58 <khilman> ldevulder: can you try the integ branch of my tree: https://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-amlogic.git

22:20 <khilman> repk: oh, looks like they switched from github, change submitted to their new gerrit: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/1111