going

Don't rush to a conclusion. If you check your first configuration before installation, you should see for the echo "$(fdisk -l | grep 'EFI')" command: /dev/sda1 8192 532479 524288 256M EFI System And after installation: (Or just insert the USB flash drive from which the installation was done) /dev/sda1 8192 532479 524288 256M EFI System /dev/nvme0n1p1 2048 411647 409600 200M ef EFI (FAT-12/16/32)

Can you expand on this? I have it working on another opi5+ running armbian right now: @ozacas If it doesn't bother you, could you post the output of the "fdisk -l" command under the spoiler for your device? I have a suspicion that the script does not analyze correctly if EDK2 is used.

Just stay tuned. Will be included in the kernel version v6.6.54 or later

Unfortunately, you did not write which version of the kernel you wrote the overlay for. I checked it out. For the EDGE kernel (v6.11.2), this is present. No overlay is required.

SPI flash can be a bootable block device

I'm sorry, I used the wrong terminology. In your case, the initial boot code (uefi-arm64), which was downloaded from here with this code. It was recorded in the image and is located on the USB flash drive (boot device) from which you started the OS. By the way, it contains the UBOOT code plus some additional code, but that's not important right now. As far as I understand from the build system code, we should have a separate partition on the boot block device that is mounted in the "/boot/efi" folder and it is associated with the initial boot code that reads it. In turn, the OS boot code writes information there when updating the kernel, adding a variant of another OS to boot. The first problem is that NVME cannot be a bootable block device. Another one is described here. That is, your USB flash drive will serve as a boot device and NVME will have OS partitions. This is one scenario. Another scenario is.... however, the script does not provide for analyzing and doing any different steps depending on which image was built with UEFI support and which memory devices will serve as future boot devices. I think I found a few problematic parts in the code. Correction work is in progress.

Good. I have always believed that devices can only boot from a SD card, eMMC or nand\nor flash (here I mean the initial boot code). But I read the RK3588\S Datasheets and realized that its BootRom can also load USB OTG. This changes the logic for choosing quite seriously. Download Stages: 1) the power is turned on and the hardware BootROM tries to read the initial boot code from the media in the manner prescribed by the hardware manufacturer. For RK3588 it is: 2)The initial boot code configures the RAM and loads the main part of UBOOT into it. 3) UBOOT configures the peripheral, loads the kernel directly or loads another loader and transfers control to it. In your case, I would probably want to place the initial boot code on the SD card and the entire file system on NVME. That is, insert a clean CD and a clean NVME into the connectors, boot from USB and run armbian-install, which will partition (clean) the media and record everything correctly. (This does not work in the current version.) What configuration do you want to get in the end?

The first thing I noticed is that the build system does not handle GPT correctly: [ 5.300511] GPT:Primary header thinks Alt. header is not at the end of the disk. [ 5.300513] GPT:14942207 != 120831999 [ 5.300515] GPT:Alternate GPT header not at the end of the disk. [ 5.300516] GPT:14942207 != 120831999 [ 5.300517] GPT: Use GNU Parted to correct GPT errors. @ozacas Did I understand correctly that your device booted from SATA? Was the image of the Armbians recorded on a SATA drive? Was the boot code not written into the soldered chip? Just to understand. Good. I will make changes and provide you with a new version of the script for testing. It will take a few days. And thanks for the information provided.

Unfortunately, the script does not do some actions or does them incorrectly. You describe it well. I will rely on this information.

You can describe the wrong behavior and attach pictures with the selection dialog interface. You can show the partition table status of all memory devices before and after the change. You can post suggestions for improving the functionality of the script here. I am changing his logic right now and your opinion may be useful. I see some kind of manual work here. Or is it some kind of intermediate script state?

Yes, the script analyzer does not cope with the task if the memory device is clean and at least one partition has not been created. P.S. You can post suggestions for improving the functionality of the script here. I am changing his logic right now and your opinion may be useful.

This is an old and well-known problem for that time. The SOC has a controller (ARISC architecture). The code of that time randomly started the controller at the maximum frequency, for example, when the OS was turned off with the sudo poweroff command. If you did not pull the plug out of the socket, then the processor chip began to warm up more than when the OS was running. You need to update the u-boot and kernel to the current versions.

--

Yes it is. If you are satisfied with how all patches are applied during the compilation process, then we will just leave everything as it is.

haven't tried. https://github.com/sicXnull/armbian-build/commit/333e462466670e9a8609771ccd05977b87800881#diff-60905755e35d9115365c06e07ef492c1e5cfde8cdd018a10496129e19b6b7b2d The first piece affects all devices and will be applied directly in the u-boot code. diff --git a/arch/arm/dts/sun50i-h616.dtsi b/arch/arm/dts/sun50i-h616.dtsi --- a/arch/arm/dts/sun50i-h616.dtsi +++ b/arch/arm/dts/sun50i-h616.dtsi @@ -324,7 +324,7 @@ pinctrl-names = "default"; pinctrl-0 = <&mmc2_pins>; status = "disabled"; - max-frequency = <150000000>; + max-frequency = <12000000>; cap-sd-highspeed; cap-mmc-highspeed; mmc-ddr-3_3v; Instead, you can specify the frequency directly in the device's DTS, if necessary. In any case, the u-boot code is more advanced and it doesn't really matter to him. This part is done in SPL: diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c --- a/drivers/mmc/sunxi_mmc.c 2024-01-08 16:37:48.000000000 +0100 +++ b/drivers/mmc/sunxi_mmc.c 2024-03-08 10:51:44.771585037 +0100 @@ -542,7 +542,7 @@ cfg->b_max = CONFIG_SYS_MMC_MAX_BLK_COUNT; cfg->f_min = 400000; - cfg->f_max = 52000000; + cfg->f_max = 12000000; if (mmc_resource_init(sdc_no) != 0) return NULL; Try to exclude it first. If you get a non-bootable system, we will need to think about how to surround this ifdef code with directives so that it does not apply to everyone.

@sicxnull Has there been a health check in your work with u-boot patches if you apply your fixes only to the configuration file and do not apply the patch piece that lowers the eMMC frequency?

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.