The same procedure can be done by fill image directly by dd without using android-tools.
Regarding partitions created by fdisk and placed at addresses which we have in the U-Boot partition tables I can say that after next system start this partitions become invisible probably U-Boot erases information during init on boot time.
Issue is that when we create partitions by fdisk and make file systems we have inodes /dev/mmcblk1p{1,2}. After reboot we have not inodes /dev/mmcblk1p{1,2} but if we start fdisk and repeat the wtite command:
fdisk /dev/mmcblk1
. . .
Command (m for help): w
then we can see the inodes /dev/mmcblk1p{1,2} again and can mount partitions. All data in that partitions exists and available.
MBR partition table is same and U-Boot doesn’t take this table.
Probably U-Boot rewrite some data in the partition or I have to use another values of start/end sectors?
I think is correct because in the U-Boot declared reserved 8Mb space after each partition
#define PARTITION_RESERVED (8*SZ_1M) // 8MB
so you can use current image and create partitions with offset in my second post:
(the sector size is 512 bites)
boot:
start sector: 352256
end sector: 434175
rootfs:
start sector: 434176
end sector: (last sector of eMMC)
Probably for the future we can remove cache and reserved partitions and do not declare reserved space after each partition. What do you think about it?
Please note that the RESERVED partition cannot be removed because in this partition the partition table is located for U-Boot an Kernel.
Also if you change the bootloder partition size then you have to do the same in kernel include/linux/mmc/emmc_partitions.h file. The kernel use this size for finding the offset of RESERVED partition where partition table is placed.
Best Regards,
Andrey K.
P.S.
I need more tests before I can share my patches.
Downloaded your image last night and (once I erased emmc) had no problems with it booting. As an experiment I took the S950X image available at arch arm and replaced the kernel, modules and boot dir in that image with the files from your build. The resulting Frankenstein image, with arch user space, works with the exception that I get errors like:
which seems to be a problem with the aarch64 getrandom syscall. I suspect that the arch arm source with the correct board file (I know x86 linux builds well - not familiar with aarch64/arm yet) and config and, if required khadas firmware blobs, would probably fix this. The arch kernel is at 3.14.79.
I have not tested wifi or bluetooth. Network & usb seem okay. For now its still running from SD. The other issue is that arch expects an initrd so when the boot ends / is ro - but a simple remount fixes that…
Any pointers on where I can find an arm guide for people who know x86 well?
I build my system by my toolchains based on GNU Libc 2.24 and GGC 5.3.0. Also I have normal system start scripts instead of systemd.
I think that is bad odea to mix binaries created by different toolchains and binaries linked with different libc. Also monolytic system exactly follows to dependencies between packages.
If you would like to use another kernel or add some package into the Radix.pro system please set up build environment and check out my platform branch radix-1.1
After build the whole system you wil can create your owm Makefiles for build other kernel and affitional packages.
Also your log say that you take 32bit binaries for armv8l architecture but my system is build for AArch64.
I agree 100% that mixing like I have done is NOT a great idea (hence the Frankenstein image comment). It does let me boot strap into arch though. Next steps are to get a build system working and rebuild the radix-1.1 kernel here. Then I want to see if I can merge and end up with a 3.14.79 build - if I get this working I will share the tree. The version I used is 64 bit though arch, at least on x86, handles both 32 & 63 bit with little pain.
Please remember that not all AArch64 based chips can run 32 bit lba32 binaries on 64bit system. And anycase the kernel and libc should be patched for such feature.
I’ve created a workaround for this issue. If you boot the kernel with an initramfs image you can call /sbin/partprobe /dev/mmcblk1 just before the rootfs is mounted. This will give you the device nodes back.