Hi, Applied the patch. No change in behaviour.
Even increasing the delay to half a second has no effect. Brandon. On Tuesday, October 25, 2022 at 2:32:07 PM UTC+1 huseyi...@gmail.com wrote: > I also have the same problem, did not test out yet but, > > > https://patchwork.ozlabs.org/project/uboot/patch/CACqvRUbw1wg7BL+3XWV4MX=7t9njn6oufc81...@mail.gmail.com/ > > <https://patchwork.ozlabs.org/project/uboot/patch/CACqvRUbw1wg7BL+3XWV4MX=7t9njn6oufc81wz7wfom-1hm...@mail.gmail.com/> > > seems related, i can also confirm the ESD relevance. When I touch some > metal groud, issue gets worsened. > > Uart shows below on hang: > U-Boot SPL 2022.10 (Oct 22 2022 - 18:54:33 +0200) > DRAM: 1024 MiB > > 29 Eylül 2022 Perşembe tarihinde saat 16:02:34 UTC+2 itibarıyla > fusibr...@gmail.com şunları yazdı: > >> *DRAM_CLK* seems to affect this. Reducing to say 432 lets the board boot >> about 70% of the time. >> >> The hang seems to be coming from the *spl_load_image *function defined >> in common/spl/spl.c, with the SPL sometimes failing to load the U-boot >> image. >> >> Could this be an issue with MMC controller timings ?? Looking at the A33 >> and R16 user manuals show the Physical Layer Spec for the former is Ver3.00 >> that for the latter is Ver2.00. Maybe this explains why the boot on the R16 >> never hangs. My current knowledge of MMC controllers is still ~nil to be >> able to read the specs and comprehend the difference. >> >> Brandon. >> >> On Thursday, September 22, 2022 at 11:08:32 AM UTC+1 Cheo Fusi wrote: >> >>> Hi Simon, >>> >>> Did you finally solve this issue?? I have the same problem with the M2M >>> variant that has no eMMC chip. The same image works well with the variant >>> that includes the eMMC. >>> >>> Brandon >>> On Tuesday, November 30, 2021 at 3:09:21 PM UTC+1 simon...@gmail.com >>> wrote: >>> >>>> Hi, >>>> >>>> I'm trying to get a banana pi M2M working on a slightly more recent >>>> version of the kernel than the 3.4 that's provided. I got some things >>>> working but u-boot isn't reliably booting from the sd card. It sometimes >>>> works but it mostly hangs after displaying the DRAM message (as shown >>>> below) >>>> >>>> ``` >>>> U-Boot SPL 2022.01-rc3 (Nov 30 2021 - 10:46:41 +0000) >>>> DRAM: 512 MiB >>>> >>>> <pressed reset> >>>> >>>> U-Boot SPL 2022.01-rc3 (Nov 30 2021 - 10:46:41 +0000) >>>> DRAM: 512 MiB >>>> >>>> <pressed reset> >>>> >>>> U-Boot SPL 2022.01-rc3 (Nov 30 2021 - 10:46:41 +0000) >>>> DRAM: 512 MiB >>>> >>>> <pressed reset> >>>> >>>> U-Boot SPL 2022.01-rc3 (Nov 30 2021 - 10:46:41 +0000) >>>> DRAM: 512 MiB >>>> >>>> <pressed reset> >>>> >>>> U-Boot SPL 2022.01-rc3 (Nov 30 2021 - 10:46:41 +0000) >>>> DRAM: 512 MiB >>>> >>>> <pressed reset> >>>> >>>> U-Boot SPL 2022.01-rc3 (Nov 30 2021 - 10:46:41 +0000) >>>> DRAM: 512 MiB >>>> >>>> <pressed reset> >>>> >>>> U-Boot SPL 2022.01-rc3 (Nov 30 2021 - 10:46:41 +0000) >>>> DRAM: 512 MiB >>>> Trying to boot from MMC1 >>>> >>>> >>>> U-Boot 2022.01-rc3 (Nov 30 2021 - 10:46:41 +0000) Allwinner Technology >>>> >>>> CPU: Allwinner A33 (SUN8I 1667) >>>> Model: BananaPi M2 Magic >>>> DRAM: 512 MiB >>>> WDT: Not starting watchdog@1c20ca0 >>>> MMC: mmc@1c0f000: 0, mmc@1c10000: 1, mmc@1c11000: 2 >>>> ``` >>>> >>>> Looking through the wiki https://linux-sunxi.org/U-Boot it looks like >>>> it could be because of the device tree, but considering it's booting some >>>> times I don't think this is the issue? It looks like SPL is always working >>>> but it's often failing to pass to u-boot proper. >>>> >>>> Any pointers on what could be wrong here? >>>> >>>> Has anyone got a bananapi m2m or similar working well with a recent >>>> kernel? I managed to get SPI working fine (i might submit a patch) but so >>>> far I haven't managed to get wifi working (a bit stuck on that) and I >>>> haven't looked much beyond that. >>>> >>>> Best regards, >>>> Simon >>>> >>> -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/9af3fdcc-5725-429c-a2f7-c8cd23dd0e73n%40googlegroups.com.
