Do I need to copy kernel binary and substitute it in grub or it is more complicated? I am not experienced linux user =) If you can post some links about how to launch another kernel it will be helpful =)
it depends on your image and your uboot-config.
basicly you need uImage (kernel itself) on boot-part and modules in rootfs (/lib/modules)
best way will be having a debug-uart-cable to see an try to boot the new uimage in Uboot
in my uboot i have defined a var for loading the new kernel
bpi=bananapi
board=bpi-r64
chip=mt7622
service=linux
device=mmc
partition=1:1
kernel=uImage
fdt=bpi-r64.dtb
kaddr=0x44000000
loadaddr=0x44000000
dtaddr=0x47000000
root=/dev/mmcblk1p2 rootfstype=ext4 rootwait
console=ttyS0,115200n1 earlyprintk
bootopts=debug=7 initcall_debug=0 androidboot.hardware=mt7622 swiotlb=512
loaddt=fatload $device $partition $dtaddr ${bpi}/${board}/${service}/dtb/${fdt}
loadkernel=fatload $device $partition $kaddr ${bpi}/${board}/${service}/${kernel}
buildargs=setenv bootargs "board=${board} console=${console} root=${root} service=${service} ${bootopts}"
newboot=run buildargs;if run loadkernel; then if run loaddt; then bootm ${kaddr} - ${dtaddr};fi;fi
run newboot
edit: change to r64 (had posted r2-version before)
based on this uEnv-file:
I use the SD card as a system disk and it works, but when copying a file of about 100MB in size, it stops and freezes. Have you encountered this problem? “sync” command will always waiting。
It stops on copying or on booting? Which image? Bpi-boot partition large enough? Why copy such large image (with rootfs and modules)?
Tried large image on bpi-r2 long time ago (with rootfs).afair it was not bootable with ~25mb+
I guess because of memory-boundaries (loadaddr+imagesize > max_mem)
Do you use my uboot or from vendor image? Also upstream till my patches (using rfb dts) only initialized 128MB RAM
The following is my disk：
root@MT7622:~# fdisk -l
Disk /dev/mmcblk0: 7.3 GiB, 7818182656 bytes, 15269888 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: F2AF147A-B77B-4440-93BD-9F787F35AB89
Device Start End Sectors Size Type
/dev/mmcblk0p1 256 1023 768 384K Linux filesystem
/dev/mmcblk0p2 1024 1535 512 256K Linux filesystem
/dev/mmcblk0p3 1536 3071 1536 768K Linux filesystem
/dev/mmcblk0p4 3072 4095 1024 512K Linux filesystem
/dev/mmcblk0p5 4096 4607 512 256K Linux filesystem
/dev/mmcblk0p6 4608 70143 65536 32M Linux filesystem
/dev/mmcblk0p7 70144 15269824 15199681 7.3G Linux filesystem
Disk /dev/mmcblk1: 7.2 GiB, 7746879488 bytes, 15130624 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: A66FE5B8-C133-4B95-A2B4-12806CC03F6B
Device Start End Sectors Size Type
/dev/mmcblk1p1 256 1023 768 384K Linux filesystem
/dev/mmcblk1p2 1024 1535 512 256K Linux filesystem
/dev/mmcblk1p3 1536 3071 1536 768K Linux filesystem
/dev/mmcblk1p4 3072 4095 1024 512K Linux filesystem
/dev/mmcblk1p5 4096 4607 512 256K Linux filesystem
/dev/mmcblk1p6 4608 70143 65536 32M Linux filesystem
/dev/mmcblk1p7 70144 15130560 15060417 7.2G Linux filesystem
Disk /dev/sda: 7.4 GiB, 7948206080 bytes, 15523840 sectors
Disk model: STORAGE DEVICE
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 26D8D206-C8B0-4258-9E61-FFC37CB4FA38
Device Start End Sectors Size Type
/dev/sda1 256 1023 768 384K Linux filesystem
/dev/sda2 1024 1535 512 256K Linux filesystem
/dev/sda3 1536 3071 1536 768K Linux filesystem
/dev/sda4 3072 4095 1024 512K Linux filesystem
/dev/sda5 4096 4607 512 256K Linux filesystem
/dev/sda6 4608 70143 65536 32M Linux filesystem
/dev/sda7 70144 15523776 15453633 7.4G Linux filesystem
root@MT7622:~#
I update the system by extracting root.tar to the root partition.
So I need to copy root.tar (> 200M) to the file system first.
I use tftp to transfer, if the root is in the SD card, then the copy file will be stuck.
If it is in usb storage or emmc, there is no problem with the tftp copy, and the speed is completed quickly.
If usb and emmc works i guess it depends on your sdcard…maybe some kind of inkompatibility
But i swa also a slowdown this weekend on my card (afair it was in 5.9/5.10)…not sure why…maybe same as yours…if i find time i can try 5.4 and maybe some between
Haha My USB is an SD card reader, so USB and SD media are actually the same. I also tried swapping two SD cards. The problem is still the same. I suspect there is a problem with the SD card driver, but there is no evidence.
Could you try different kernels to figure out when problem starts? Then we can look for changes in wifi driver
Okay, I will take time to conduct multiple comparison tests
What is the difference between your uboot sdcard driver and the official uboot sdcard driver?
2020-07+ should be same as upstream…before imho there was any bug, i had fixed locally
But why uboot? I talked about kernel
The kernel did not report an error. I tried multiple versions of yours and all versions have the same problem. There must be a problem with writing to sdcard, and writing to a file will wait indefinitely.
My debugging method is to use ftp to transfer files to adcard, and then it freezes. Do you have the same situation?
Linux MT7622 5.4.77 #3 SMP PREEMPT Fri Nov 13 18:21:00 AKST 2020 aarch64
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
root@MT7622:~#
root@MT7622:~# uname -a
Linux MT7622 5.4.77 #3 SMP PREEMPT Fri Nov 13 18:21:00 AKST 2020 aarch64 GNU/Linux
root@MT7622:~#Can you try reverting reset-patches form emmc? Maybe they causing sdcard issue
Have you tried older uboot from my repo? Maybe sdcard issue is caused by recent uboot changes.