Allwinner A33/R16 mainline u-boot

[Simon Jouet]

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

[Cheo Fusi]

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

[Cheo Fusi]

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.

[Mahmut Dikçizgi]

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/

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ı:

[Cheo Fusi]

Hi,

Applied the patch. No change in behaviour. 

Even increasing the delay to half a second has no effect.

Brandon.

[Cheo Fusi]

Here is another weird observation; Adding a printf statement to end of board_init_f() in arch/arm/mach-sunxi/board.c causes the hang to almost entirely disappear. The board now boots about 99% of the time.

Any ideas on why printf affects anything ??

Brandon.