Helios64 u-boot does not build anymore after we bumped to 2022.07

[Igor]

Just a reminder, if someone wants to fix it.

[balbes150]

16.10.2022 в 18:05, Igor сказал:

Just a reminder, if someone wants to fix it.

It can be fixed, but the question is, who will check the result?

[Igor]

32 minutes ago, balbes150 said:

It can be fixed, but the question is, who will check the result?

Just leave this problem to someone with a device and know-how.

[BipBip1981]

Hi,

 @balbes150: explain how you can fix it and i test to build with your fix then i test on my helios64

[balbes150]

16 часов назад, BipBip1981 сказал:

explain how you can fix it and i test to build with your fix then i test on my helios64

I don't understand, what is there to explain? See the error, make corrections (makes a patch) and check in the work.

[BipBip1981]

I have a helios64, but i'm not dev and i can't make a patch.

I only can test on Helios64 if all work good after à full compile with a patch.

 

[balbes150]

13 часов назад, BipBip1981 сказал:

I have a helios64, but i'm not dev and i can't make a patch.

I only can test on Helios64 if all work good after à full compile with a patch.

 

I'll think about what I can do.

[BinaryWaves]

How can we freeze the uboot package so it does not upgrade to this broken version?

[iav]

On 10/19/2022 at 1:19 PM, balbes150 said:

who will check the result?

I will run build and boot result image on Helios64 hardware in case somebody fix error.

[balbes150]

In theory, I can move Helios 64 support to the "media" group (and fix build errors), but I'm not sure if this is a good idea (I don't have real hardware for quick testing and debugging) . This will significantly change the entire structure (switching to a different startup option and a different kernel). And before doing this, you need to discuss it with all those interested and those who will be affected by it.

[iav]

I think moving to media group will be too much for NAS device.

[BinaryWaves]

I'm rather new and not sure what switching to a media group would entail but I think I'd probably agree with iav. I really ❤️ my H64 but we are a niche community and most of us use them for low-power homelab NAS i'm assuming.

 

I have finally got my H64 stable with OMV6 but I am having issues with smb shares and such that i'm still working on

Edited November 6, 2022 by BinaryWaves

[prahal]

PR https://github.com/armbian/build/pull/4480

[iav]

Then, thanks to Prahal, bootable images for Helios64 can be build again.

 

 

[ebin-dev]

@prahal Thanks for fixing this bug !

 

You mentioned, that you are investigating the emmc hs400 issue. Once you (or someone else) found a solution to it, please let us know.

 

We could then try to test newer versions of the linux kernel and see what remains to be done.

[n3o]

@iav What are bootable images? What is u-boot?

Edited December 10, 2022 by n3o

[n3o]

@BinaryWaves Luckily I have upgraded to OMV6 and, almost SMB, still work fine... Do You have NUT plugin? I don't have more notifactions when I turnon Helios from UPS plugin... You can confirm me that the switch from buster to bullseye don't reduce stability? I have choose buster image when I have made clean install of armbian, but for the upgrading to OMV 6 automatically has switched to bullseye

[iav]

9 hours ago, n3o said:

What are bootable images? What is u-boot?

In current thread that means "Armbian was not available for Helios64 hardware for a time. But then it fixed, and anyone can make sdcard with fresh armbian system for Helios64 device".

 

u-boot — software, use by armbian on first seconds after device powered on.

[n3o]

 

12 hours ago, iav said:

In current thread that means "Armbian was not available for Helios64 hardware for a time. But then it fixed, and anyone can make sdcard with fresh armbian system for Helios64 device".

 

u-boot — software, use by armbian on first seconds after device powered on.

So now I can make image following this tut https://docs.armbian.com/Developer-Guide_Build-Preparation/ ?

Edited December 11, 2022 by n3o

[iav]

yes. at least it works for me now.

[prahal]

On 11/26/2022 at 12:58 PM, ebin-dev said:

You mentioned, that you are investigating the emmc hs400 issue. Once you (or someone else) found a solution to it, please let us know.

 

@ebin-dev
6.2 should have it fixed. Though it requires testing. I did build and install the kernel from Armbian edge 6.1.11-rockchip64 and added the few missing packages for the core regulator for the stable 6.2 repository https://github.com/torvalds/linux/commits/master/drivers/regulator/core.c , that is:

cb3543cff90a regulator: core: fix deadlock on regulator enable
0debed5b117d regulator: core: Fix resolve supply lookup issue
8f3cbcd6b440 regulator: core: Use different devices for resource allocation and DT lookup
ba62319a42c5 regulator: core: fix resource leak in regulator_register()
da46ee19cbd8 regulator: core: fix module refcount leak in set_supply()
0591b14ce039 regulator: core: fix use_count leakage when handling boot-on
dc8d006d15b6 regulator: core: use kfree_const() to free space conditionally
f2b41b748c19 regulator: core: fix unbalanced of node refcount in regulator_dev_lookup()
fd1845069711 regulator: devres: Add devm_regulator_bulk_get_exclusive()

All are probably not required but I have not yet sorted out which ones matter (and it will become moot as soon as 6.2 enter armbian (except if a new commit breaks the hs400es on rk339 anew.

(Likely the fix would be 0debed5b117d regulator: core: Fix resolve supply lookup issue)

 

The test was a simple mount of the emmc this kernel and hs400es reenabled in the dts, write a file, unmount, remount, read the file. No error in dmesg.

[prahal]

 It turns out I only had one of the above patch applied:

Displaying message: * [\e[33mu\e[0m][\e[32mc\e[0m] p-0001-regulator-devres-Add-devm_regulator_bulk_get_exclusi.patch  info
Displaying message: * [\e[33mu\e[0m][\e[32mc\e[0m] p-0002-regulator-core-fix-unbalanced-of-node-refcount-in-re.patch failed wrn
Displaying message: * [\e[33mu\e[0m][\e[32mc\e[0m] p-0003-regulator-core-use-kfree_const-to-free-space-conditi.patch failed wrn
Displaying message: * [\e[33mu\e[0m][\e[32mc\e[0m] p-0004-regulator-core-fix-use_count-leakage-when-handling-b.patch failed wrn
Displaying message: * [\e[33mu\e[0m][\e[32mc\e[0m] p-0005-regulator-core-fix-module-refcount-leak-in-set_suppl.patch failed wrn
Displaying message: * [\e[33mu\e[0m][\e[32mc\e[0m] p-0006-regulator-core-fix-resource-leak-in-regulator_regist.patch failed wrn
Displaying message: * [\e[33mu\e[0m][\e[32mc\e[0m] p-0007-regulator-core-Use-different-devices-for-resource-al.patch failed wrn
Displaying message: * [\e[33mu\e[0m][\e[32mc\e[0m] p-0008-regulator-core-Fix-resolve-supply-lookup-issue.patch failed wrn
Displaying message: * [\e[33mu\e[0m][\e[32mc\e[0m] p-0009-regulator-core-fix-deadlock-on-regulator-enable.patch failed wrn

and one that is unrelated. So I would say that armbian edge should do for hs400es on rk3399. Though if I remove:

assigned-clock-rates = <150000000>;
from the dts (which falls back to rk3399.dtsi value which is 200000000) I get the old error:
 

Spoiler

helios64 login: [  899.804369] mmc1: running CQE recovery
[  899.805836] ------------[ cut here ]------------
[  899.806326] mmc1: cqhci: spurious TCN for tag 8
[  899.806961] WARNING: CPU: 0 PID: 386 at drivers/mmc/host/cqhci-core.c:787 cqhci_irq+0x61c/0x9a0
[  899.807831] Modules linked in: quota_v2 quota_tree veth xt_nat xt_tcpudp xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xfrm_user xfrm_algo iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 xt_addrtype iptable_filter bpfilter br_netfilter bridge aufs r8152 snd_soc_hdmi_codec snd_soc_rockchip_i2s snd_soc_core leds_pwm snd_compress snd_pcm_dmaengine snd_pcm hantro_vpu rockchip_vdec(C) panfrost snd_timer v4l2_vp9 gpu_sched snd videobuf2_dma_contig gpio_charger pwm_fan drm_shmem_helper soundcore sg rockchip_rga v4l2_h264 videobuf2_dma_sg v4l2_mem2mem videobuf2_memops videobuf2_v4l2 fusb302 videobuf2_common tcpm videodev lm75 mc typec cpufreq_dt gpio_beeper cfg80211 rfkill ledtrig_netdev nfsd auth_rpcgss nfs_acl lockd grace sunrpc ip_tables x_tables autofs4 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx raid1 raid0 multipath linear lz4 dm_mod raid10 realtek dwmac_rk md_mod stmmac_platform stmmac pcs_xpcs adc_keys
[  899.816735] CPU: 0 PID: 386 Comm: kworker/0:2H Tainted: G         C         6.1.12-rockchip64 #trunk

[  899.817620] Hardware name: Helios64 (DT)
[  899.818014] Workqueue: kblockd blk_mq_run_work_fn
[  899.818519] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[  899.819194] pc : cqhci_irq+0x61c/0x9a0
[  899.819587] lr : cqhci_irq+0x61c/0x9a0
[  899.819970] sp : ffff800008007b20
[  899.820305] x29: ffff800008007b20 x28: ffff00000ebd8080 x27: ffff00000ebd80a4
[  899.821029] x26: ffff00000e3fa100 x25: ffff00000e3fa080 x24: 0000000000000080
[  899.821752] x23: ffff00000ce5e008 x22: 0000000000000002 x21: ffff00000ce5e000
[  899.822474] x20: 0000000000000008 x19: ffff00000ebd8080 x18: 0000000000000000
[  899.823198] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000
[  899.823920] x14: 0000000000000000 x13: 0000000000031e48 x12: ffff60001952fd3e
[  899.824638] x11: 1fffe0001952fd3d x10: ffff60001952fd3d x9 : 1fffe0001952fd3d
[  899.825356] x8 : dfff800000000000 x7 : ffff0000ca97e9eb x6 : ffff60001952fd3e
[  899.826073] x5 : 0000000000000001 x4 : dfff800000000000 x3 : ffff80000817b650
[  899.826789] x2 : 0000000000000007 x1 : 62d2eabe2646cc00 x0 : 0000000000000000
[  899.827505] Call trace:
[  899.827760]  cqhci_irq+0x61c/0x9a0
[  899.828122]  sdhci_arasan_cqhci_irq+0xc0/0x100
[  899.828580]  sdhci_irq+0x15c/0x1ab8
[  899.828944]  __handle_irq_event_percpu+0x84/0x340
[  899.829423]  handle_irq_event_percpu+0x18/0x70
[  899.829873]  handle_irq_event+0x64/0xc8
[  899.830266]  handle_fasteoi_irq+0x140/0x270
[  899.830700]  generic_handle_domain_irq+0x48/0x68
[  899.831165]  gic_handle_irq+0x50/0x140
[  899.831561]  call_on_irq_stack+0x2c/0x58
[  899.831965]  do_interrupt_handler+0xec/0x108
[  899.832404]  el1_interrupt+0x38/0x60
[  899.832781]  el1h_64_irq_handler+0x18/0x28
[  899.833204]  el1h_64_irq+0x64/0x68
[  899.833554]  preempt_count_sub+0x28/0x118
[  899.833965]  _raw_spin_unlock_irqrestore+0x34/0x60
[  899.834450]  sdhci_cqe_enable+0x1f8/0x348
[  899.834861]  sdhci_arasan_cqe_enable+0xfc/0x148
[  899.835317]  cqhci_request+0x1b0/0xaa8
[  899.835700]  mmc_cqe_start_req+0xf8/0x290
[  899.836109]  mmc_blk_mq_issue_rq+0x6c4/0xc20
[  899.836550]  mmc_mq_queue_rq+0x1f4/0x418
[  899.836957]  blk_mq_dispatch_rq_list+0x3d4/0xed0
[  899.837434]  __blk_mq_sched_dispatch_requests+0x17c/0x250
[  899.837975]  blk_mq_sched_dispatch_requests+0x5c/0x98
[  899.838480]  __blk_mq_run_hw_queue+0xbc/0x108
[  899.838929]  blk_mq_run_work_fn+0x2c/0x40
[  899.839350]  process_one_work+0x44c/0x8d8
[  899.839761]  worker_thread+0x70/0x718
[  899.840136]  kthread+0x164/0x180
[  899.840479]  ret_from_fork+0x10/0x20
[  899.840853] ---[ end trace 0000000000000000 ]---
[  899.844775] EXT4-fs (mmcblk1p1): mounted filesystem with writeback data mode. Quota mode: none.

 

[prahal]

I tried a more extensive test with all armbian (and the above regulator ones above) patches removed (patches removed for an unrelated test) and the test failed CQHCI.

I still have to try the extensive test with devm patch applied and also with the above patchset fixed to apply to armbian kernel 6.1.12.

 

The read test works:
 

dd if=/dev/mmcblk1 of=/dev/null bs=16M iflag=direct
931+1 enregistrements lus
931+1 enregistrements écrits
15634268160 octets (16 GB, 15 GiB) copiés, 65,3501 s, 239 MB/s

 

but with emmc part1 mounted on /mnt, the write test fails:

sudo dd if=/dev/sda of=/mnt/test2.dat bs=16M count=500 oflag=direct
dd: erreur d'écriture dans '/mnt/test2.dat': Erreur d'entrée/sortie
1+0 enregistrements lus
0+0 enregistrements écrits
0 octet copié, 0,856469 s, 0,0 kB/s

with error:
 

[ 2240.820878] mmc1: running CQE recovery                                                                
[ 2240.824858] ------------[ cut here ]------------                                                      
[ 2240.825339] mmc1: cqhci: spurious TCN for tag 12  
(...)

 

[BinaryWaves]

@n3o So far my build has remained stable. Not sure about NUT plugin.

 

@prahal thanks for your bug fix! <3

[n3o]

little offtopic: somebody can tell me how update uboot?

from here 

in zsh console the command "dmesg | "mmc.*: SDHCI controller on fe330000.mmc \[fe330000.mmc\] using ADMA"" doesn't work  and command "dpkg -l "linux-u-boot-helios64*"" give me the following output

 

Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name                          Version      Architecture Description
+++-=============================-============-============-=================================
ii  linux-u-boot-helios64-current 21.08.9      arm64        Uboot loader 2021.07

 

So I have the following questions:

1. What is the equvalent zsh shell command of "dmesg | "mmc.*: SDHCI controller on fe330000.mmc \[fe330000.mmc\] using ADMA"" bourne shell command?

2. linux-u-boot-helios64-edge 23.02.0-trunk arm64        Uboot loader 2022.07 (used by prahal in the linked topic) is stable?

3. Should be used only with armbian edge or can be used also with bullseye?

4. Can be used with linux kernel 5.15.93? Some month ago I have installed from open media vault wireguard plugin, but I don't know why the installation break after update to linux kernel 6 and I must reinstall all from begin . I have make a backup of microsd image a week ago, but I don't want repeat the fail

5. In omv dashboard, in section update, isn't showed Armbian 23.02 ... how can I update it? it's possible add an option to keep stored on sd kernel 5.15.93 in case of issues? And if some issues occurs, what command should send from ssh?

[n3o]

somebody can help me? Moreover I have tried to search linux-u-boot-helios64-edge 23.02.0-trunk on web but I can't find it... where prahal have found it?

[prahal]

On 5/17/2023 at 4:04 PM, n3o said:

What is the equvalent zsh shell command of "dmesg | "mmc.*: SDHCI controller on fe330000.mmc \[fe330000.mmc\] using ADMA"" bourne shell command?

 

This is shell agnostic but you miss the program name "grep" after the pipe so you should:

dmesg | grep "mmc.*: SDHCI controller on fe330000.mmc \[fe330000.mmc\] using ADMA"

or as dmesg is a ring buffer and early message could end up lost):

journalctl -k -b | grep "mmc.*: SDHCI controller on fe330000.mmc \[fe330000.mmc\] using ADMA"

 

[prahal]

26 minutes ago, n3o said:

I have tried to search linux-u-boot-helios64-edge 23.02.0-trunk on web but I can't find it... where prahal have found it?

lastest linux-u-boot-helios64-edge published was 22.02.1.

 

I built linux-u-boot-helios64-edge 23.02.0-trunk locally by cloning Armbian build repository https://github.com/armbian/build/:
 

git clone https://github.com/armbian/build.git

cd build

./compile.sh docker BOARD=helios64 BRANCH=edge BUILD_ONLY="u-boot" RELEASE=bullseye KERNEL_CONFIGURE=no

 

That is I build inside a docker container (as I am on Debian which is not an officially supported build host.

If you want to also compile the kernel add ",kernel" to BUILD_ONLY, see https://docs.armbian.com/Developer-Guide_Build-Options/

 

You will then have your packages in the build/output/debs/ directory. Copy them to your helios64 and install with "dpkg -i <deb>".

[prahal]

On 5/17/2023 at 4:04 PM, n3o said:

Should be used only with armbian edge or can be used also with bullseye?

 

I myself run bullseye with an edge kernel, u-boot, and armbian-bsp (in fact everything that was build by the now obsolete KERNEL_ONLY=yes option to compile.sh. Now replaced by BUILD_ONLY="u-boot,kernel,armbian-config,armbian-zsh,plymouth-theme-armbian,armbian-firmware,armbian-bsp".

 

There could be a sysfs or device path rename that breaks armbian scripts. At one time we had the fan path that changed. But this is with kernel packages. u-boot one only matters to the kernel. That is the location and name of the dtb in /boot matters, though I have not heard of anything changing in that regard for a long while (not an u-boot issue per se but more an armbian u-boot configuration issue).

So if one day you have an issue due to a mismatch between u-boot, armbian configuration and script, and the kernel you can pretty easily revert (though it requires learning to rewrite the u-boot).

You can extract the steps from the armbian script that does the job when you run the armbian tool /usr/sbin/nand-sata-install:

/usr/lib/u-boot/platform_install.sh

mostly its write_uboot_platform function:

     if [[ -f $1/rksd_loader.img ]]; then
        dd if=$1/rksd_loader.img of=$2 seek=64 conv=notrunc status=none > /dev/null 2>&1;
     else
     	if [[ -f $1/u-boot.itb ]]; then
            dd if=$1/idbloader.img of=$2 seek=64 conv=notrunc status=none > /dev/null 2>&1;
            dd if=$1/u-boot.itb of=$2 seek=16384 conv=notrunc status=none > /dev/null 2>&1;
        else
            if [[ -f $1/uboot.img ]]; then
                dd if=$1/idbloader.bin of=$2 seek=64 conv=notrunc status=none > /dev/null 2>&1;
                dd if=$1/uboot.img of=$2 seek=16384 conv=notrunc status=none > /dev/null 2>&1;
                dd if=$1/trust.bin of=$2 seek=24576 conv=notrunc status=none > /dev/null 2>&1;
            else
                echo "Unsupported u-boot processing configuration!";
                exit 1;
            fi;
        fi;
    fi

where $2 is the device file where you want to install U-Boot.

nand-install-script get it via:

partition="$(sudo blkid | tr -d '":' | grep "$(sed -e 's/^.*root=//' -e 's/ .*$//' < /proc/cmdline)" | awk '{print $1}')"; echo "${partition::-2}"

 which is the device where your kernel has its root partition setup. But if you want to restore u-boot on eMMC from an SD card image this will give you /dev/mmcblk0 (which is the SD card) instead of /dev/mmcblk1 (the eMMC ).

 

So as this script does the command to write the u-boot from the command line will depend on the format of the u-boot in the package. For  linux-u-boot-helios64-edge 23.02.0-trunk:

ls /usr/lib/linux-u-boot-edge-helios64_23.02.0-trunk_arm64
idbloader.img u-boot.itb

that is /usr/lib/linux-u-boot-edge-helios64_23.02.0-trunk_arm64 contains u-boot.itb so the command are:

dd if=$1/idbloader.img of=$2 seek=64 conv=notrunc status=none > /dev/null 2>&1;
dd if=$1/u-boot.itb of=$2 seek=16384 conv=notrunc status=none > /dev/null 2>&1;

with $1 equals /usr/lib/linux-u-boot-edge-helios64_23.02.0-trunk_arm64 and $2 equals the target device file to write u-boot to (here for emmc /dev/mmcblk1 and for the SD card /dv/mmcblk0).

Which gives to write to the eMMC when rescuing from an SD card on helios64:

dd if=/usr/lib/linux-u-boot-edge-helios64_23.02.0-trunk_arm64/idbloader.img of=/dev/mmcblk0 seek=64 conv=notrunc status=none
dd if=/usr/lib/linux-u-boot-edge-helios64_23.02.0-trunk_arm64/u-boot.itb of=/dev/mmcblk0 seek=16384 conv=notrunc status=none

 

If you want to write to the SD card you could even write the u-boot from a PC via an SD card reader. You will then have to get the u-boot binaries from your deb package (a deb package is a compressed tar archive) and on your PC replace the of=/dev/mmcblk0 by the device file your card reader exhibits the SD card as.

 

[n3o]

48 minutes ago, prahal said:

lastest linux-u-boot-helios64-edge published was 22.02.1.

 

I built linux-u-boot-helios64-edge 23.02.0-trunk locally by cloning Armbian build repository https://github.com/armbian/build/:

 thank You for the answer ..  change something from linux-u-boot-helios64-current 23.02.0-trunk to linux-u-boot-helios64-edge 23.02.0-trunk ?

 

I don't know use docker, can You compile u-boot only? Can I use U-boot 23.02.0 both with kernel 5.19.53 that 6.2.0?