Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Orange Pi Zero 3 | 1.5 GB RAM variant looses Ethernet adapter on soft reboot #6938

Closed
1 task done
MichaIng opened this issue Feb 23, 2024 · 9 comments · Fixed by #7064
Closed
1 task done

Orange Pi Zero 3 | 1.5 GB RAM variant looses Ethernet adapter on soft reboot #6938

MichaIng opened this issue Feb 23, 2024 · 9 comments · Fixed by #7064
Labels
External bug 🐞 For bugs which are not caused by DietPi. Orange Pi Zero 3 Solution available 🥂 Definite solution has been done
Milestone

Comments

@MichaIng
Copy link
Owner

MichaIng commented Feb 23, 2024

Mainline U-Boot does not support the 1.5 GB RAM variant, and the Orange Pi bootloader has this issue. For more details: #6594

Also we should keep an eye on the work of iuncuim from OpenWRT:

@MichaIng MichaIng added External bug 🐞 For bugs which are not caused by DietPi. Orange Pi Zero 3 labels Feb 23, 2024
@MichaIng MichaIng added this to the v9.2 milestone Feb 23, 2024
@MichaIng MichaIng modified the milestones: v9.2, v9.3 Mar 17, 2024
@lalakii
Copy link

lalakii commented Mar 23, 2024

I have the 1.5GiB board

I found out the difference by comparing the source code.

source code: u-boot/arch/arm/mach-sunxi/dram_sun50i_h616.c

static unsigned long mctl_calc_size(const struct dram_config *config)
{
        u8 width = config->bus_full_width ? 4 : 2;

        /* 8 banks */
        unsigned long size;
        size = (1ULL << (config->cols + config->rows + 3)) * width * config->ranks;
        //  -----   CONFIG_DRAM_SUN50I_H616_TRIM_SIZE=y   -----
        size = (size * 3) / 4;
        //  ------------------------ END -----------------------
        return size;
} 

image

@lalakii
Copy link

lalakii commented Mar 23, 2024

I think I may need to add a configuration menu to the mainline u-boot, but I don't know much about that, would anyone do that.

@MichaIng
Copy link
Owner Author

MichaIng commented Mar 23, 2024

Ah nice, you just nees to add size = (size * 3) / 4; and this works for U-Boot and also the final Linux system booted?

This looks so easy and obvious, I wonder whether iuncuim did not find that.

Also not sure how to implement into mainline U-Boot. Since this is not done in the device tree, I also have no other idea than basically adding this very same flag. At least it can potentially serve other H616/H618 boards as well.

EDIT: Ah, I think he does the very same for H616 boards like Zero 2. I am currently in China where gist.github.com is blocked, but based on snippets, he edits the same function. The problem IIRC was that the physical RAM size could not be checked the same way on H618, hence he aimed to do it without flag but dynamically bases on hardware. I could imagine that U-Boot is not happy to accept such SoC specific flags in the main config, but not sure whether anyone asked.

EDIT2: Not the SoC is the difference, but LPDDR3 vs LPDDR4. However, this means we can use mainline U-Boot, only applying a one-line patch.

I will ask at Armbian whether they would accept an additional build target for this, otherwise we can do with a fork, hosting the build on our server, so the issue is solved for the 1.5G variant as well.

@lalakii
Copy link

lalakii commented Mar 23, 2024

Hello!

I've tried different kernels and found that they all have the wrong temperature information, which makes them unbootable

One problem has been identified so far:

[    2.143164] thermal thermal_zone0: gpu-thermal: critical temperature reached, shutting down
[    2.151581] reboot: HARDWARE PROTECTION shutdown (Temperature too high)
[    2.185438] reboot: Power down

My old kernel could boot fine because I removed the temperature module.

@lalakii
Copy link

lalakii commented Mar 23, 2024

However there doesn't seem to be anything else I can do about this problem. :(

@MichaIng
Copy link
Owner Author

Next week I can generate a U-Boot build which matches the one we use for the 1/2/4 GB variants, just with this patch added. That one (using the Armbian build system), does have the right temperatures.

@lalakii
Copy link

lalakii commented Mar 24, 2024

This u-boot seems to have a lot of problems with "dram_init".

In the "mctl_calc_size" method body.

both values have the potential to occur.

        u8 width = config->bus_full_width ? 4 : 2;

        // Sometimes it's 2, sometimes it's 4

When the memory size is incorrectly recognized, the system may crash if the memory usage exceeds the actual amount available.

@MichaIng
Copy link
Owner Author

Hmm, one would expect that config->bus_full_width is the correct condition for width to result in the correct memory size?

@MichaIng MichaIng modified the milestones: v9.3, v9.4 Apr 16, 2024
@MichaIng MichaIng added the Solution available 🥂 Definite solution has been done label May 8, 2024
@MichaIng
Copy link
Owner Author

MichaIng commented May 8, 2024

Fixed with: #7064
Armbian just added a patch to fix the 1.5 GB RAM detection in mainline U-Boot. I compiled a new package and added it to our APT repository, to be installed on the 1.5 GB RAM variant as well. If you want to test it now:

apt purge linux-u-boot-orangepizero3-next
apt install linux-u-boot-orangepizero3-current
source /usr/lib/u-boot/platform_install.sh
# To show progress and errors, in case
eval "$(declare -f write_uboot_platform | sed -e 's| > /dev/null 2>&1||g' -e 's|status=none|status=progress|g')"
write_uboot_platform "$DIR" "$(lsblk -npo PKNAME "$G_ROOTFS_DEV")"

Works well, with correct RAM size, and Ethernet adapter remains on reboot:

root@OrangePiZero3:~# free -m
               total        used        free      shared  buff/cache   available
Mem:            1420         142        1254           2          91        1278
Swap:              0           0           0
root@OrangePiZero3:~# ip l
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether <MAC> brd ff:ff:ff:ff:ff:ff
    altname end0
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DORMANT group default qlen 1000
    link/ether <MAC> brd ff:ff:ff:ff:ff:ff

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
External bug 🐞 For bugs which are not caused by DietPi. Orange Pi Zero 3 Solution available 🥂 Definite solution has been done
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants