Release v0.8

[tym2k1]

Merged PRs:
#69
#70
#71 counterpart with adjustments - see 200cf5b
#76

[PLangowski]

Something very unusual is happening.

Booting hangs on [ 1.769553] Waiting for root device /dev/mmcblk0p2... and never continues. It doesn't fall back to shell either.

First we thought that the error can be resolved by specifying the partition UUID in the boot command:

setenv bootargs console=${console} console=tty1 root=PARTUUID=076c4a2a-02 rootwait panic=10 ${extra}

Thisfixes the problem with mounting the root partition, but booting still does not complete. It hangs on:

[    7.091486] dwmac-sun8i 1c30000.ethernet end0: configuring for phy/mii link mode
[    7.184108] random: crng init done

And falls back to recovery shell.
We tried increasing log verbosity to debug the issue. Here's where the weird stuff happened: The system booted. We then tried booting it with unchanged root parameter. It also booted. For some reason adding debug-related options fixes the issue. We have no idea why. Below are the steps required to boot the system:

1. Power on the RTE and go interrupt booting to get into U-boot shell
2. In U-boot shell execute the following commands:

setenv boot_part 2
setenv bootargs console=${console} console=tty1 root=/dev/mmcblk0p${boot_part} rootwait panic=10 ${extra} ignore_loglevel initcall_debug
ext4load mmc 0:${boot_part} ${fdt_addr_r} /boot/${fdtfile}
ext4load mmc 0:${boot_part} ${kernel_addr_r} /boot/uImage
booti ${kernel_addr_r} - ${fdt_addr_r} || bootm ${kernel_addr_r} - ${fdt_addr_r}

The commands are taken from recipes-bsp/u-boot/u-boot/orange-pi-zero/boot.cmd. The only difference is the presence of ignore_loglevel initcall_debug.

[macpijan]

[    7.091486] dwmac-sun8i 1c30000.ethernet end0: configuring for phy/mii link mode
[    7.184108] random: crng init done

This is probably unrelated log. Look in dmesg or journactl -x for erros.

Check mount --all in recovery shell and check if it does not complain.

Check fstab. Do you have all partitions /dev/mmcblk0p[1-4] visible in OS?

I can try removing my tmp, rebuild and test again on my unit.

[macpijan]

In the presence of these "weirdnesses you may want to check on different hardware unit as well.

[macpijan]

@PLangowski I was able to trigger the Waiting for root device /dev/mmcblk0p2... problem as well. Your conclusions are incorrect. This problem is completely random. Just try booting the board 10 times for instance with no changes to the boot commands.

Sometimes the SD card gets enumerated as mmcblk0, sometimes as mmcblk1. There is a race condition, the SDIO WiFi chip sometimes gets enumerated first as mmc0, and the SD card gets mmc1 then. We do not use WiFi, so we could even remove it (disable in devicetree) as a quick workaround to this issue.

https://paste.dasharo.com/?a383dc8cd91aca31#2Mt88gsFh2o1xQcnMw2HMVoPGLBv4122eX5JFxD5hEvQ

Let's focus on SPI first here.

[PLangowski]

@macpijan The GPIO expander pins have been shifted by 112. I don't know the reason why this happened. Some service tries to export GPIO 404 during late boot, but fails to do so. We should probably modify that so that it exports 516, 517 and 518.

[PLangowski]

Fixed the SPI problem by modifying the RteCtrl config.

Now after boot the GPIOs are correctly exported and can be used to control SPI.

[PLangowski]

I also disabled the WiFi chip. It seems that we fixed all the problems.

[macpijan]

This commit e3937c9 could use some explanation as well.

Also, it's name is rather long, we do not always need to include the full path.

[macpijan]

Do we know why this has changed?

[PLangowski]

Unfortunately I don't know

[PLangowski]

@macpijan I added the explanation 93fb19f

[macpijan]

Looks good enough for me to get merged into develop.

This thread bother me though: #73 (comment)

In the end, we must understand this.