> -----Original Message-----
> From: Sven Van Asbroeck <thesven73@xxxxxxxxx>
> Sent: 2019年6月10日 23:47
> To: Robin Gong <yibin.gong@xxxxxxx>
> Subject: Re: [v8] media: imx: add mem2mem device
> On Mon, Jun 10, 2019 at 5:09 AM Robin Gong <yibin.gong@xxxxxxx> wrote:
> >
> > I can reproduce once enable your config to build firmware in kernel,
> > but no such issue if load sdma firmware from rootfs as
> > imx_v6_v7_defconfig. Maybe firmware built in function broken by some
> > patches. Could you try with the default firmware loading way which is from
> rootfs(/lib/firmware/imx/sdma/sdma-imx6q.bin)?
>
> This is it ! If I add the firmware to the kernel directly, I see the crash.
> But if I use the firmware fall-back mechanism, there is no crash.
> And if I build imx-sdma as a module, and insmod it later, there is also no crash.
>
> I patched imx-sdma so it logs the adler32 checksum of the firmware it's
> loading (I tried using the kernel crypto API, but it doesn't work this early in the
> boot). I notice that the firmware is always the same, crash or no
> crash:
>
> firmware in-kernel (crash):
> [ 1.370424] imx-sdma 20ec000.sdma: firmware hash: 69BC0F09
> firmware fallback (no crash):
> [ 6.466394] imx-sdma 20ec000.sdma: firmware hash: 69BC0F09
>
> My guess: this could be a timing issue. If the sdma driver loads 'too early', the
> boot crash will happen. Maybe the driver needs to check for a missing
> dependency on boot, and -EPROBE_DEFER ?
>
> Robin, should I make a bug report? If so, who do I send this to?
>
Sven, no any dependency from sdma driver view. The only difference between directly loading firmware
from kernel and rootfs is the former spend more time during kernel boot and such timing may cause
the crash. The issue is not 100% in my side, about 20% possibility, which looks like 'timing issue' . Another
interesting thing is that every time the crash stop at somewhere drm, and After I disable ipu and display
which use drm in i.mx6q.dtsi, the issue is gone on my i.mx6q-sabreauto board.
Could you have a try with below patch as mine? If the issue is gone on your side, we could involve drm guys to
look into it.
diff --git a/arch/arm/boot/dts/imx6q.dtsi b/arch/arm/boot/dts/imx6q.dtsi
index 7175898..5b21b3f 100644
--- a/arch/arm/boot/dts/imx6q.dtsi
+++ b/arch/arm/boot/dts/imx6q.dtsi
@@ -217,6 +217,7 @@
<&clks IMX6QDL_CLK_IPU2_DI1>;
clock-names = "bus", "di0", "di1";
resets = <&src 4>;
+ status = "disabled";
ipu2_csi0: port@0 {
reg = <0>;
@@ -300,6 +301,7 @@
display-subsystem {
compatible = "fsl,imx-display-subsystem";
ports = <&ipu1_di0>, <&ipu1_di1>, <&ipu2_di0>, <&ipu2_di1>;
+ status = "disabled";
};
};
