going

sudo armbian-install

@Nick A I understand you. Working with the source code and making patches within the framework of the build system is a sad business. Let's try to sort it out. I'm writing this for everyone. Don't read it if it's familiar to you. First, basic knowledge about git: A git is a chain of related git objects. The git object is the compressed difference between the current state and the previous one. The Git object has a name in the form of a 40-digit hexadecimal numeric word. Each object is tightly linked to the previous (parent) and subsequent (child) objects. Concepts such as HEAD, tag, branch are references to a specific git object. The working tree is the git state extracted to the working directory. In previous posts, we talked about u-boot. Let's check what we have in the build system. My build system is located in the VM in the folder: /home/leo/armbian leo@armbuild:~/armbian/cache/sources/u-boot-worktree/u-boot/v2024.01$ git branch + master * u-boot-edge-bananapim3 leo@armbuild:~/armbian/cache/sources/u-boot-worktree/u-boot/v2024.01$ git log --pretty=oneline -3 866ca972d6c3cabeaf6dbac431e8e08bb30b3c8e (HEAD -> u-boot-edge-bananapim3, tag: v2024.01) Prepare v2024.01 82750ce44226e5f2b3bbcd79cf7b3ba3dfd3de4d arm: dts: iot2050: Fix by syncing from Linux dbb124cf6888da9581834a3c17b02f958a8afacf configs: j7200: Remove HBMC_AM654 config Enter your data from the github here. It is important. git config --global user.email "you@example.com" git config --global user.name "Your Name" Let's add all the changed files to the monitored state and make a commit: leo@armbuild:~/armbian/cache/sources/u-boot-worktree/u-boot/v2024.01$ sudo git add --all leo@armbuild:~/armbian/cache/sources/u-boot-worktree/u-boot/v2024.01$ sudo git commit -m "The Armbian changes" [u-boot-edge-bananapim3 dcf395c104] The Armbian changes 52 files changed, 682 insertions(+), 16 deletions(-) create mode 100644 arch/arm/dts/sun50i-a64-recore.dts create mode 100644 arch/arm/dts/sun50i-h313-x96q-lpddr3.dts create mode 100644 configs/recore_defconfig create mode 100644 configs/x96q_lpddr3_defconfig Now we will see: leo@armbuild:~/armbian/cache/sources/u-boot-worktree/u-boot/v2024.01$ git log --pretty=oneline -3 dcf395c1044533320913373b3b8da980ac49ac73 (HEAD -> u-boot-edge-bananapim3) The Armbian changes 866ca972d6c3cabeaf6dbac431e8e08bb30b3c8e (tag: v2024.01) Prepare v2024.01 82750ce44226e5f2b3bbcd79cf7b3ba3dfd3de4d arm: dts: iot2050: Fix by syncing from Linux The HEAD and branch links point to the new git object. But the v2024.01 tag continues to point to 866ca972d6c3cabeaf6dbac431e8e08bb30b3c8e Let's add the debugging code and make a commit: leo@armbuild:~/armbian/cache/sources/u-boot-worktree/u-boot/v2024.01$ sudo nano drivers/mmc/sunxi_mmc.c leo@armbuild:~/armbian/cache/sources/u-boot-worktree/u-boot/v2024.01$ sudo git add drivers/mmc/sunxi_mmc.c leo@armbuild:~/armbian/cache/sources/u-boot-worktree/u-boot/v2024.01$ sudo git commit -m "define DEBUG macros for sunxi mmc" Look at the last commit. This is what will be extracted using the command "git format-patch -1": leo@armbuild:~/armbian/cache/sources/u-boot-worktree/u-boot/v2024.01$ git log -p -1 commit c5a54a85e206c32c4a17aa573c8f409899c2a77a (HEAD -> u-boot-edge-bananapim3) Author: The-going <48602507+The-going@users.noreply.github.com> Date: Wed Sep 25 09:09:47 2024 +0000 define DEBUG macros for sunxi mmc diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c index 8b684929e0..c32c9bda28 100644 --- a/drivers/mmc/sunxi_mmc.c +++ b/drivers/mmc/sunxi_mmc.c @@ -33,6 +33,8 @@ #include "sunxi_mmc.h" +#define DEBUG + #ifndef CCM_MMC_CTRL_MODE_SEL_NEW #define CCM_MMC_CTRL_MODE_SEL_NEW 0 #endif We will extract these changes to the target directory: leo@armbuild:~/armbian/cache/sources/u-boot-worktree/u-boot/v2024.01$ git format-patch -1 -o /home/leo/armbian/patch/u-boot/u-boot-sunxi/ /home/leo/armbian/patch/u-boot/u-boot-sunxi/0001-define-DEBUG-macros-for-sunxi-mmc.patch leo@armbuild:~/armbian/cache/sources/u-boot-worktree/u-boot/v2024.01$ mv /home/leo/armbian/patch/u-boot/u-boot-sunxi/0001-define-DEBUG-macros-for-sunxi-mmc.patch /home/leo/armbian/patch/u-boot/u-boot-sunxi/define-DEBUG-macros-for-sunxi-mmc.patch leo@armbuild:~/armbian/cache/sources/u-boot-worktree/u-boot/v2024.01$ cat /home/leo/armbian/patch/u-boot/u-boot-sunxi/define-DEBUG-macros-for-sunxi-mmc.patch From c5a54a85e206c32c4a17aa573c8f409899c2a77a Mon Sep 17 00:00:00 2001 From: The-going <48602507+The-going@users.noreply.github.com> Date: Wed, 25 Sep 2024 09:09:47 +0000 Subject: [PATCH] define DEBUG macros for sunxi mmc --- drivers/mmc/sunxi_mmc.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c index 8b684929e0..c32c9bda28 100644 --- a/drivers/mmc/sunxi_mmc.c +++ b/drivers/mmc/sunxi_mmc.c @@ -33,6 +33,8 @@ #include "sunxi_mmc.h" +#define DEBUG + #ifndef CCM_MMC_CTRL_MODE_SEL_NEW #define CCM_MMC_CTRL_MODE_SEL_NEW 0 #endif -- 2.34.1 I have removed the prefix number of the patch file name so that the patch is applied last. If I do git format-patch -1 v2024.01 I will get the changes that are stored in the git object referenced by this v2024.01 tag. Do I need to write here how to correctly add multiple changes to the kernel?

git format-patch --help

Is there a link to the source code?

This patch is bad. It changes the general code and has an impact on other devices. Armbian cannot afford such behavior. I apologize for the short remark. Most likely, the TV set-top box already has a boot code in eMMC on the boot0 partition. This prevents the Armbian code, which is located on the first main section, from running.

yes, any feedback you have @going would be great. This board is like 95% ready to go at this point. solving EMMC boot would be huge CONFIG_SUPPORT_EMMC_BOOT=y CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x40 CONFIG_MMC_SUNXI_SLOT_EXTRA=2 This should be present in the default configuration for the device. And please post the UART output if possible. If that's not possible, then I won't be able to help.

You are incorrectly adding patches to the build system. Patches should be extracted using the "git format-patch" command and should contain small explanations of what and for what reason these changes were made. You should not add the patch somewhere in the middle of the series list. This can lead to subsequent patches being applied incorrectly and becoming inapplicable. As a result, we get a compilation error at best, or incorrectly compiled code at worst.

This is a bad patch. The problem is different.

We will be able to boot the OS from eMMC on the bananapi-m3 board after this pull request is accepted. PR (#7252) Use armbian-install. With respect.

It's hard to argue with that. But the squashfs file system is basically an opportunity to use a compressed root file system to save space. If we set the task as ensuring fault tolerance of the root file system, then we need to perform a whole set of measures. And mounting the root file system with the read-only flag is one of the points. By the way, u-boot is able to work with the squashfs file system. I thought your question was about that. With respect.

Quite interesting! If you try to explain your ultimate goal and the reasons that led you to this decision, perhaps I can give you some advice.

At the moment, I still don't understand the reason. Please publish the name of the eMMC chip, a piece of the schematic diagram of its connection. I will deal with this further.

If your device is in the same condition, I will ask you to provide some additional information about the downloaded operating system. Your case is unique. Your device and mine have the same OS and the same set of packages installed. But the armbian-install script behaves completely differently and crashes in your case. I need to understand why this is happening and correct the erroneous behavior. Please post the output of the following commands: cat /proc/cmdline | tr " " "\n" lsblk -Py df -h sudo blkid 1) You can use a utility from the manufacturer of the chip or device. If this software exists. 2) You can become a hacker, listen to the following harmful tips, or find them on the Internet: Boot the device in any way and get access to the command line with superuser rights. The bootloader, u-boot or other, can be written in whole or in parts to three locations on the eMMC: /dev/mmcblkXboot0 /dev/mmcblkXboot1 /dev/mmcblkX X - This is the number for your eMMC In order for the device not to boot from eMMC, it is necessary to clear those areas in which parts of the bootloader can be placed. sudo su echo 0 > /sys/block/mmcblkXboot0/force_ro dd if=/dev/zero of=/dev/mmcblkXboot0 bs=1M count=4 echo 0 > /sys/block/mmcblkXboot1/force_ro dd if=/dev/zero of=/dev/mmcblkXboot1 bs=1M count=4 dd if=/dev/zero of=/dev/mmcblkX bs=1M count=10 After these steps, your device will be able to boot from the SD card correctly. You can also use the helpful tips described in great detail in the wiki documentation for NanoPi R5S. With respect

Boot from the SD. Try to clear (write zeros) the first 10 megabytes on the /dev/mmcblk1 disk. Try the installation again from the CD.

Let's try to figure out where you are. Boot from the SD and print the output of the df -h command

Is your OS loaded from eMMC? Your OS is loaded from eMMC!! Insert the SD card on running OS and run armbian-install

leo@bananapim3:~$ sudo ./check-command.sh [sudo] пароль для leo: # ls =: /usr/bin/ls # grep =: /usr/bin/grep # awk =: /usr/bin/awk # blkid =: /usr/sbin/blkid # tr =: /usr/bin/tr # lsblk =: /usr/bin/lsblk # xargs =: /usr/bin/xargs # sync =: /usr/bin/sync # mount =: /usr/bin/mount # df =: /usr/bin/df # head =: /usr/bin/head # cat =: /usr/bin/cat # sed =: /usr/bin/sed # mktemp =: /usr/bin/mktemp # nl =: /usr/bin/nl # chroot =: /usr/sbin/chroot # lsof =: /usr/bin/lsof # parted =: /usr/sbin/parted # partprobe =: /usr/sbin/partprobe # mkfs =: /usr/sbin/mkfs # fdisk =: /usr/sbin/fdisk ===== root_partition_device=/dev/mmcblk0 emmccheck=/dev/mmcblk2 diskcheck=sda mmcblk2

No Create a check-command.sh file: #!/bin/bash cm="ls grep awk blkid tr lsblk xargs sync mount df head cat sed mktemp nl chroot lsof parted partprobe mkfs fdisk" for c in $cm do echo "# $c =: $(command -v $c)" done echo "=====" root_uuid=$(sed -e 's/^.*root=//' -e 's/ .*$//' < /proc/cmdline) root_partition=$(blkid | tr -d '":' | grep "${root_uuid}" | awk '{print $1}') root_partition_name=$(echo $root_partition | sed 's/\/dev\///g') root_partition_device_name=$(lsblk -ndo pkname $root_partition) root_partition_device=/dev/$root_partition_device_name emmccheck=$(ls -d -1 /dev/mmcblk* 2>/dev/null | grep -w 'mmcblk[0-9]' | grep -v "$root_partition_device") diskcheck=$(lsblk -l | awk -F" " '/ disk / {print $1}' | grep -E '^sd|^nvme|^mmc' | grep -v "$root_partition_device_name" | grep -v boot) echo "root_partition_device=$root_partition_device" echo "emmccheck=$emmccheck" echo "diskcheck=$diskcheck" and make it executable. chmod +x check-command.sh Run on board and publish sudo ./check-command.sh

I'm shocked. We use the same versions of the system packages. There is something else that needs to be checked. Wait for me to type it now.

@sami Please publish your OS and BASH version. leo@bananapim3:~$ lsblk --version lsblk from util-linux 2.38.1

It looks very strange. It looks like this to me: leo@bananapim3:~$ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS sda 8:0 0 0B 0 disk mmcblk0 179:0 0 7,4G 0 disk └─mmcblk0p1 179:1 0 7,4G 0 part /var/log.hdd / mmcblk2 179:8 0 7,3G 0 disk └─mmcblk2p1 179:9 0 7,2G 0 part mmcblk2boot0 179:16 0 4M 1 disk mmcblk2boot1 179:24 0 4M 1 disk zram0 253:0 0 1005,7M 0 disk [SWAP] zram1 253:1 0 50M 0 disk /var/log zram2 253:2 0 0B 0 disk leo@bananapim3:~$ bash --version GNU bash, версия 5.2.15(1)-release (arm-unknown-linux-gnueabihf) leo@bananapim3:~$ lsb_release -a No LSB modules are available. Distributor ID: Debian Description: Armbian_community 24.8.0-trunk.104 bookworm Release: 12 Codename: bookworm I booted from the SD card and sudo armbian-install

Please try to replace the /usr/sbin/armbian-install file with this new version: packages/bsp/common/usr/sbin/armbian-install Please show the output of the `lsblk` command. Please post screenshots of the armbian-install dialog.

Cubietruck log : [ 11.673947] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43362-sdio for chip BCM43362/1 [ 11.677634] brcmfmac mmc1:0001:1: Direct firmware load for brcm/brcmfmac43362-sdio.cubietech,cubietruck.bin failed with error -2 [ 11.677685] brcmfmac mmc1:0001:1: Falling back to sysfs fallback for: brcm/brcmfmac43362-sdio.cubietech,cubietruck.bin .... [ 12.141976] Bluetooth: hci0: BCM20702A [ 12.142021] Bluetooth: hci0: BCM20702A1 (001.002.014) build 0000 [ 12.144184] cfg80211: failed to load regulatory.db [ 12.418687] brcmfmac mmc1:0001:1: Direct firmware load for brcm/brcmfmac43362-sdio.clm_blob failed with error -2 [ 12.418731] brcmfmac mmc1:0001:1: Falling back to sysfs fallback for: brcm/brcmfmac43362-sdio.clm_blob [ 12.453585] EXT4-fs (zram1): mounted filesystem 4d22a70b-63d9-448d-86f1-00d5d3260b7f r/w without journal. Quota mode: none. [ 12.457556] Bluetooth: hci0: BCM: firmware Patch file not found, tried: [ 12.457592] Bluetooth: hci0: BCM: 'brcm/BCM20702A1.cubietech,cubietruck.hcd' [ 12.457602] Bluetooth: hci0: BCM: 'brcm/BCM20702A1.hcd' [ 12.457611] Bluetooth: hci0: BCM: 'brcm/BCM.cubietech,cubietruck.hcd' [ 12.457621] Bluetooth: hci0: BCM: 'brcm/BCM.hcd' .... [ 12.756951] brcmfmac: brcmf_c_process_clm_blob: no clm_blob available (err=-2), device may have limited channels available [ 12.756988] brcmfmac: brcmf_c_process_txcap_blob: no txcap_blob available (err=-2) [ 12.757625] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM43362/1 wl0: Apr 22 2013 14:50:00 version XXX.XXX.195.89.6 FWID 01-b30a427d .... [ 27.278196] ieee80211 phy0: brcmf_p2p_create_p2pdev: timeout occurred [ 27.278246] ieee80211 phy0: brcmf_cfg80211_add_iface: add iface p2p-dev-wlan0 type 10 failed: err=-5 I do not know what to do about it. 😁 The armbian patches contain many fixes for h616(8) chips including AC 200. I just can't make a decision when changing the fixes. Just because I can't check how to do it right, one way or the other. Is it possible to add another column with the names of the chips so that it looks something like this: Board name | cpu | Kernel version | --------------------|-----|------------------------| Orange Pi Zero Plus | h5 | 6.6.43-current-sunxi64 | --------------------|-----|------------------------| Cubietruck | a20 | 6.6.43-current-sunxi | --------------------------------------------------- And the question. Is there a message distribution service if the test contains any error?

@FRANK333 Try to install this kernel: linux-6.6.43/linux-image-current-sunxi_24.8.0-trunk.510_armhf linux-dtb-current-sunxi/linux-dtb-current-sunxi_24.8.0-trunk.510_armhf__6.6.43 In order to analyze the situation, we need to see part of the DMESG command with an error or part of the system log with an error.

Which core is in the latest test (uname -r)? What is the name of the utility shown in the screenshot?