hexdump

@DWP - running s905 from emmc is very complex and far from easy - you can have a look at this thread to get an idea about this topic:

but be careful with such scripts and check them by hand to make sure they do not touch the emmc low level or your created partitions ... for copying over "rsync -axADHSX --no-inc-recursive --delete /source/ /target" always worked well for me - be careful with the "--delete" and note that the source should have a "/" appended and the target not if you want target to be a 1:1 copy of source good luck and best wishes - hexdump

@winnt5 - maybe start with data only and see if you can handle it well from an sd-card booted system and then maybe move on from there ... maybe you can just partition everything from cache on (i.e. after its starting poiint if there is nothing reserved/hidden inbetween - better double check the layout a few times) as you like it as all those should be android partitions and not related to boot ... there is always a chance that something goes wrong and you brick the box - maybe do a dd dump of the full device beforehand ... in the end you are on your own if you play around with this

@winnt5 - any partitioning tool should like fdisk, gdisk etc. - just make sure you are creating an mbr partition table and not gpt and best is to some detailed mode if available in the tool used to be able to hit the block numbers of the data partition exactly good luck and best wishes - hexdump

@winnt5- you could boot and run from usb and from there create a btrfs filesystem with zstd compression on emmc data, rsync everything over, adjust fstab in it for btrfs and try that - i'm using zstd comressed btrfs root for years now (not with armbian) and it works very stable and saves close to half of the space - another option is to run from usb and put a swap partition or file to emmc - i think swapping/paging is most proably the reason for the performance problems you see when running from usb. good luck and best wishes - hexdump

@winnt5 - it is quite normal that you do not see any partitions on emmc from the android system, as that uses hardcoded partitioning and not a normal mbr or gpt partition table ... also what @SteeMansays can be true: that there is no emmc at all in the box but just nand - this is easy to find out: just run "fdisk -l" on the box and if you can see another mmcblk device besides your sd card then you most probably have proper emmc. in case you have real emmc there are two options: the safe one to not touch emmc at all to not break your locked bootloader or the risky one to write an mbr partition table to the emmc which only covers the data partition of android - do not even think about touching any other partition/area besides the large data partition at the end of the emmc as some of the other partitions might be magic and required for booting (holding the dtb or other stuff required to boot - amlogic boxes are horrible in this direction) ... for that you would need to find out at which sector the user data partition starts from android (some math required maybe) and you should double check that the first 512bytes on emmc are empty via "hexdump -C" (i.e. writing the mbr there will not overwrite anything else) ... it worked for me at least on a mii s905x box with locked bootloader but there is no guarantee that it will work for you as well - so better chooese the safe option if you prefer to keep the box working for sure ... there might even be a way in the middle to hardcode a partition covering the data partition are also with a mainline kernel - for that reasearching about mtdparts might be a good idea - never tried that myself - this way you at least would not have to write a partition table to emmc ... just for completeness: this thread might be interesting to read as well as on s905 it is very complicated as well as bootloader and partition table overlap for the emmc case and some people were quite creative trying to overcome this - best wishes and good luck - hexdump

not sure if its related, but it might be worth to give this kernel patch a try: https://patchwork.kernel.org/project/linux-amlogic/patch/20221116143523.2126-1-the.cheaterman@gmail.com/ ...

@noom - this is what is possible with it so far, i.e. it boots, kdb and usb works (with some restrictions) - https://github.com/aarch64-laptops/debian-cdimage/issues/21# ... so its something in case you would like to help moving it forward, but its far from generally useable ... best wishes - hexdump

@s-petersen - what kind of u-boot are you using on this device? i guess you use the u-boot on the device to load and boot the kernel from usb? - this might actually work as you seem to have proven

@chewitt - not really automated, but at least a way to get the acs info from a box boot block: look at an existing acs file for that type of soc - usually it is possible to find the signature of its beginning in the boot area of a box dump and iirc the end is clear from size and some free space afterwards as well - this worked well for me for g12a and sm1 where acs can be assembed in properly when building new boot blocks - see: https://github.com/hexdump0815/u-boot-misc/blob/d75cf6cbb8f95d7b32ab7f66111c79196d7f7c07/readme.gxy#L153-L158 for gxl i extracted the bl* parts (one of which also contains the ram timing) from the box boot blocks via glximg and reassembled new bootblocks based on them - see: https://github.com/hexdump0815/u-boot-misc/blob/b10b9a5aca46438233fde86f96b452d76d7158f8/readme.gxl#L115-L160 but i guess you know most of that already best wishes - hexdump

hi @chewitt - i cannot test it as i gave my k2 away a while ago, but i would be curious about what you did still ... can you maybe say a bit about it or link the patches used? best wishes - hexdump

i think amlogic socs do not support booting from usb ... there is some usb boot mode which is something quite different: sending over a kernel or u-boot via usb from another system using some very special protocol and i guess this is not what you are looking for - no idea if its even supported on the s805 - see https://github.com/superna9999/pyamlboot best wishes - hexdump

@jock and JMCC: i think this is what you ment: https://github.com/hexdump0815/u-boot-misc/blob/master/readme.rk3328#L43-L53 - right? i think you had it initially in your rk322x instructions, but dropped it at some point. best wishes - hexdump

@SteeMan - in case you want to experiment (i.e. not sure if it really works), you might play around with chainloading the g12a-u-boot.bin (s905x2) and sm1-u-boot.bin (s905x3) from https://github.com/hexdump0815/u-boot-misc/releases/tag/200926-01 or gxb-u-boot.bin (s905) or gxl-u-boot.bin (s905x) from https://github.com/hexdump0815/u-boot-misc/releases/tag/200718-01 ... basic chainloading goes like this - https://github.com/hexdump0815/imagebuilder/blob/master/boot/boot-amlogic_gx-aarch64/s905_autoscript.txt - maybe compare it to the balbes150 boot scripts for fancier ways and most probably better armbian integration ... the files mostly exist in a serial version for serial console and another one for hdmi output and usb keyboard input (which sometimes works and sometimes not) ... better ignore the boot-xyz.dd file at the links above - they are for booting amlogic boxes without the legacy u-boot, but using them is quite complicated and risky (you can seriously brick the box worst case) as mentioned all this is without any warranty or support, but it might be a good starting point for experiments good luck and best wishes - hexdump