09:05 <kcxt> marex: the ehci-msm usb controller fixes are ready to go, they're assigned to you on patchwork but I'm happy to take them through the qcom tree if you'd prefer? https://patchwork.ozlabs.org/project/uboot/list/?series=451491

09:35 <kcxt> maybe this is a silly question, but why the %$*£ does enabling CONFIG_BINMAN add runtime code? I am solely using binman to build a custom image, I don't need "initcall_run_r(): initcall initr_binman() failed"

09:36 <kcxt> bah ok BINMAN_FDT can be disabled

12:56 <marex> kcxt: qcom tree is just fine

16:48 <sjg1> qschulz: Just checking if you saw https://github.com/open-source-firmware/flat-image-tree/pull/22

17:58 <RoganDawes> Hey folks. I have a question about the i.MX6, and Serial Download Protocol. Note this is in context of Secure Boot (HAB). My signed image boots from NAND fine, but if I send it via USB, it fails to run. I am using a hacked up version of imx_usb that does NOT clear the DCD field, because otherwise it would not be properly signed. I suspect this is

17:58 <RoganDawes> the root of the problem, that it is trying to initialise the memory controller twice, and is getting stuck in the process. This seems plausible, because if I use my hacked imx_usb to download a working unsigned image to a non-secured mx6ull, it also fails to boot. So, my question is: What is the most likely reason that the boot fails? Because the

17:58 <RoganDawes> memory gets de-configured, but the processor is trying to execute from it?

17:59 <RoganDawes> Ultimately, I'm trying to see if I can boot the signed NAND image without having to have a version that has been signed after clearing the DCD field.

18:01 <Caterpillar2> I am waiting for approval to https://source.denx.de Gitlab since 30 May. How long does it usually take for getting approval?

18:02 <Caterpillar2> oh I missed the warning about sendin an email. Bah

18:19 <cambrian_invader> RoganDawes: the boot rom clears the DCD before verifying

18:19 <cambrian_invader> so you have to send an image where it was signed with the DCD cleared

18:19 <cambrian_invader> but the image that you send has to have the DCD filled in

18:20 <RoganDawes> I presume that is the difference between NAND boot and SDP boot?

18:20 <cambrian_invader> yes, in non-SDP boot the DCD doesn't get cleared so what you send and what you sign is the same

18:22 <RoganDawes> I'm not convinced that is true, however. If I send an image read from the NAND via SDP, and I let imx_usb clear the DCD field while downloading (because it sends the DCD first in a separate step to prepare the DDR), then the signature fails to verify and imx_usb returns an error message. However, if I hack imx_usb to not clear DCD while

18:22 <RoganDawes> downloading, then I don't get the HAB error message, and it tries to execute the code (and then hangs).

18:23 <cambrian_invader> that's just what I recall from doing this a while back

18:23 <cambrian_invader> are you using SPL?

18:24 <RoganDawes> no

18:24 <RoganDawes> To demonstrate:

18:25 <RoganDawes> imx_usb ~/u-boot-wink.imx #u-boot using the system version that DOES clear DCD

18:25 <RoganDawes> failed (security 0x12343412, status 0x3318c000)

18:25 <cambrian_invader> well my only other suggestion was that I had a problem with DRAM init in SPL

18:26 <RoganDawes> ./imx_usb ~/u-boot-wink.imx # using my hacked version that doesn't clear DCD

18:26 <cambrian_invader> although generally you can'

18:26 <RoganDawes> succeeded (security 0x12343412, status 0x88888888)

18:26 <cambrian_invader> t reinit dram when executing from it

18:26 <RoganDawes> jumping to 0x877ff400

18:27 <RoganDawes> yes, that is my fear. Although I have just discovered nxp's spsdk, which has an instruction "SKIP_DCD_HEADER". So I'm not sure how that works, or even if it is implemented in the mx6 chips, but it's worth a shot!

18:31 <cambrian_invader> how do you end up reconfiguring the memory?

18:39 <RoganDawes> Well, because the image downloaded still has the DCD field populated. So when the bootrom has finished verifying the signature, it does its usual boot process, which includes processing the DCD block if it is non-zero. (This is my assumption, but it makes sense given what I am seeing, and what I have read)

18:42 <RoganDawes> ie. imx_usb downloads the DCD block separately, configuring the DDR. It then sends the entire u-boot.imx to the target address in DDR (now that it has been configured), and calls jump <target address>. bootrom validates the signature successfully, because it hasn't been tampered with (i.e. DCD has not been cleared), and tries to execute its boot

18:42 <RoganDawes> processes, starting with the DCD block, which deconfigured the DDR, and the cpu fails to access the next instruction and panics.

18:43 <RoganDawes> cambrian_invader: ^^

18:44 <RoganDawes> If Wink had only used SPL, this might have been avoidable, but this was also 2016, so forgivable, I suppose :-D

19:00 <RoganDawes> OH! I just realised that the signature does not include the contents of the DCD table! So, I should be able to provide an innocuous DCD command that does nothing (or enough commands to match the size of the DCD) when I download the image AFTER executing the real DCD, and still have it validate!

19:04 <RoganDawes21> *sob* I misread the AN. The diagram shows that the table is unsigned, but the CSF does cover it.