So I made an archiso installation media for the qualcomm-based ThinkPad X13s.
And the other day I saw someone got EndeavourOS ARM installer working on the M1, so I figured it would also work for the ThinkPad! It did actually work, with a lot of finagling 
Here is my writeup which is a work in progress:
Hereās a Demo of me booting a GNOME install with the eos grub background: Booting EndeavourOS ARM on ThinkPad X13s - YouTube
real niceā¦ congrats on this 
Nice work. I am impressed.
If I remember correctly, you also have a PineBook Pro. How does the ThinkPad X13 compare to PineBook Pro as far as response. Is it as quick or quicker?
Anyway, congrats with your project.
Pudge
EDIT:
Looked at your first URL. You have a github repository set up, a GPG key, the whole enchilada !
It is faster, better build quality, and pricier than the Pinebook Pro, it is benchmark much closer to a recent-gen i5, and I think running linux instead of Windows 11 ARM unlocks even more performance.
For my edification, in step 11.IV and 11.V the Archlinux āgenericā image is downloaded and installed. I did not see where the linux-aarch64 kernel was changed to something else. Is the linux-aarch64 kernel used in the final OS ?
I also have a couple of suggestions for your process if you are interested. I didnāt just throw them out there in this post, as I did not want to appear to be critiquing your work.
Pudge
Itās not the final version for sure, and I am open to feedback good or bad 
To answer your question, linux-aarch64 does not work for the X13s yet as support is still being mainlined. For now one can install from my github pacman ārepoā the linux-x13s package which should be drop in replacement.
The first suggestion is the pacstrap command. Hereās why.
In steps 11.iv and 11.v a rootfs is downloaded from the Archlinux arm repository as
wget http://os.archlinuxarm.org/os/ArchLinuxARM-aarch64-latest.tar.gz
Which isnāt exactly what is wanted. Sounds like your change kernels and possibly more.
Then in step 12.viii you add more packages as
pacman -Syu base linux-x13s x13s-firmware grub git vim arch-install-scripts efibootmgr networkmanager network-manager-applet dialog os-prober mtools dosfstools base-devel
This can be accomplished in one fell stroke using pacstrap.
Once the storage device is created and mounted, then instead of downloading an image from Archlinux ARM and installing the image with bsdtar, pacstrap can be run to install necessary packages from a file list. Here is an example:
In line 61 of the script
pacstrap -cGM MP - < $(pwd)/build-configs/pkglist-rpi.txt
MP is a mount point for the storage device so you could substitute /dev/sdb (notice, no partition number) which would be a uSD or whatever partitioned and formatted to your specifications.
pkglist-rpi.txt is the list of packages to install.
Here is how I would create the package list.
Run your current process through Step 11 or however far it takes to just get a bootable rootfs.
Then boot the rootfs. log in as root. then
pacman -Q > pkglist.txt
This will yield a temporary list of every package in the rootfs and would look like this snippet
attica 5.106.0-1
attr 2.5.1-3
audiocd-kio 23.04.2-1
audit 3.1.1-1
autoconf 2.71-4
automake 1.16.5-2
avahi 1:0.8+r22+gfd482a7-1
Not usable because it contains the version numbers
awk '{print $1}' pkglist.txt > pkglist-x13s.txt
Now you should have a permanent file with all the files in the rootfs minus the version numbers.
Insert a fat 32 Thumb drive to the computer, mount it, and copy the pkglist-x13s.txt to the thumb drive.
In a computer with a full OS copy the pkglist-x13s.txt where it can be easily edited.
Now add all the packages listed in Step 12.viii to the pkglist-x13s.txt file and substitute the drop in kernel and kernel-headers and any other subtitutions.
Go through the steps again but use pacstrap to install the packages instead of downloading the Archlinux ARM Generic image.
Then at the appropriate place, create your image you put on github.
May take a little tinkering, but should be doable. Just look at man pacstrap and check which options to use.
Just food for thought.
Pudge
thank you for the interesting tips. I will try it out when I get some more free time
@Pudge one issue i am having with grub bootloader is that when i run grub-mkconfig -o /boot/grub/grub.cfg it does not add a initrd /initramfs-linux.img line in my menuentry; I have to add that line manually which is a pain. Maybe it has something to do with dracut which is something I donāt have experience with.
So far, Archlinx ARM and EnOS ARM is not installing dracut by default. Just my personal opinion that dracut doesnāt gain much for ARM. Every image is set up for a Standard Hardware by device which doesnāt change. Every RPi 4b is like every other RPi 4b (not really, but the minor hardware changes between Hardware versions donāt enter into the picture OS wise).
On the x86_64 side of things. If you randomly choose 10 EnOS users and looked at the hardware differences, you would probably end up with 10 different hardware combinations. That is when dracut shines. Again, just my subjective opinion based on my Linux experiences.
Pudge
So I updated the write-up, here is the new link (wish I could edit the original post): https://github.com/ironrobin/archiso-x13s/wiki/EndeavourOS-Tutorial
Updates include:
Nice. I edited your OP with the new tutorial URL. Please check it to make sure I did what you wanted.
Next question. Are you using a storage device (such as a uSD card) to create the image on then make the image file from there?
Pudge
I donāt understand the question. I just forked an version of aarch64 archiso for the x13s. https://wiki.archlinux.org/title/archiso I think this works because this laptop is UEFI compatible. No need for uboot here.
When you run pacstrap, what is the target, a storage device (such as a uSD) or to memory?
Then when you create your distributed image, the source file would be the results of pacstrap and other configuration, and the target would be an img.xz or tar.zst file for distribution.
I hope that makes sense.
Pudge
I think I understand. Would one of those compressed files be useful for you in eos development?
Right now I am targeting a partition on my nvme so a storage device.
I was going to mention using loop devices, but if you are targeting a partition on a nvme device, I donāt think it would reduce the time of the process enough to matter. So as Roseannadanna on Saturday Night Live used to say, āNever Mindā.
Pudge
I had to refer this to Joe as I do not have write access to the Community Editions.
The pull request has been committed.
Thank You for your input on this, much appreciated.
Pudge