pista

@jock Ok, got it. Yes, the issue with S905 where ROM is using sector 0 of eMMC doesn't affect SD booting. It is a problem only when you are trying to boot from eMMC.

@jock @hexdump So, it didn't work for me. I've inserted both primary and backup GPT at the end of the eMMC: # xxd -a -g 0 emmc_gpt.bin 00000000: 00000000000000000000000000000000 ................ ----------------- * MBR 000001c0: 0200ee27e9be01000000ffdfea000000 ...'............ 000001d0: 00000000000000000000000000000000 ................ 000001e0: 00000000000000000000000000000000 ................ 000001f0: 000000000000000000000000000055aa ..............U. ----------------- 00000200: 4546492050415254000001005c000000 EFI PART....\... ----------------- 00000210: cc7a5ba1000000000100000000000000 .z[............. PRIMARY HEADER 00000220: ffdfea00000000002200000000000000 ........"....... 00000230: dedfea0000000000f0aa3b318995fc43 ..........;1...C 00000240: 9a17bc786b4c16fe0200000000000000 ...xkL.......... 00000250: 8000000080000000b6d57abf00000000 ..........z..... 00000260: 00000000000000000000000000000000 ................ * ----------------- 00000400: af3dc60f838472478e793d69d8477de4 .=....rG.y=i.G}. ----------------- 00000410: 596f0b4087be074b856fc934c732f8e6 Yo.@...K.o.4.2.. PRIMARY ENTRIES 00000420: 00a02b0000000000ffdf310000000000 ..+.......1..... 00000430: 00000000000000004c0069006e007500 ........L.i.n.u. 00000440: 78002000660069006c00650073007900 x. .f.i.l.e.s.y. 00000450: 7300740065006d000000000000000000 s.t.e.m......... 00000460: 00000000000000000000000000000000 ................ 00000470: 00000000000000000000000000000000 ................ 00000480: af3dc60f838472478e793d69d8477de4 .=....rG.y=i.G}. 00000490: 23c888f98a92884c93efa31ce6df24a9 #......L......$. 000004a0: 00e0310000000000dedfea0000000000 ..1............. 000004b0: 00000000000000004c0069006e007500 ........L.i.n.u. 000004c0: 78002000660069006c00650073007900 x. .f.i.l.e.s.y. 000004d0: 7300740065006d000000000000000000 s.t.e.m......... 000004e0: 00000000000000000000000000000000 ................ * ----------------- 00004400: af3dc60f838472478e793d69d8477de4 .=....rG.y=i.G}. ----------------- 00004410: 596f0b4087be074b856fc934c732f8e6 Yo.@...K.o.4.2.. BACKUP ENTRIES 00004420: 00a02b0000000000ffdf310000000000 ..+.......1..... 00004430: 00000000000000004c0069006e007500 ........L.i.n.u. 00004440: 78002000660069006c00650073007900 x. .f.i.l.e.s.y. 00004450: 7300740065006d000000000000000000 s.t.e.m......... 00004460: 00000000000000000000000000000000 ................ 00004470: 00000000000000000000000000000000 ................ 00004480: af3dc60f838472478e793d69d8477de4 .=....rG.y=i.G}. 00004490: 23c888f98a92884c93efa31ce6df24a9 #......L......$. 000044a0: 00e0310000000000dedfea0000000000 ..1............. 000044b0: 00000000000000004c0069006e007500 ........L.i.n.u. 000044c0: 78002000660069006c00650073007900 x. .f.i.l.e.s.y. 000044d0: 7300740065006d000000000000000000 s.t.e.m......... 000044e0: 00000000000000000000000000000000 ................ * ----------------- 00008400: 4546492050415254000001005c000000 EFI PART....\... ----------------- 00008410: e68b23ae00000000ffdfea0000000000 ..#............. BACKUP HEADER 00008420: 01000000000000002200000000000000 ........"....... 00008430: dedfea0000000000f0aa3b318995fc43 ..........;1...C 00008440: 9a17bc786b4c16fedfdfea0000000000 ...xkL.......... 00008450: 8000000080000000b6d57abf00000000 ..........z..... 00008460: 00000000000000000000000000000000 ................ * 000085f0: 00000000000000000000000000000000 ................ ----------------- and set CONFIG_EFI_PARTITION_ENTRIES_OFF to the offset of the Primary Entries. In mainline u-boot I tested: => mmc dev 2 switch to partitions #0, OK mmc2(part 0) is current device => mmc part ## Unknown partition table type 0 => part list mmc 2 ## Unknown partition table type 0 => gpt verify mmc 2 No partition list provided - only basic check GUID Partition Table Header signature is wrong: 0x0 != 0x5452415020494645 gpt_verify_headers: *** ERROR: Invalid GPT *** Verify GPT: error! => gpt guid mmc 2 GUID Partition Table Header signature is wrong: 0x0 != 0x5452415020494645 find_valid_gpt: *** ERROR: Invalid GPT *** find_valid_gpt: *** Using Backup GPT *** 313baaf0-9589-43fc-9a17-bc786b4c16fe success! Note, that the last command reads the GUID from the Backup GPT, but none of the other commands work. I have to say, I'm puzzled by the GPT implementation in u-boot. I would have expected it to work the same as linux kernel - with kernel cmd line Linux uses the backup GPT wo problems. It looks like if u-boot can't find a valid Primary GPT, it doesn't use the Backup even it is aware of it. So, without having u-boot working with only the Backup GPT I can't even attempt to replace the AML u-boot with mainline. This is because the boot ROM is looking for the boot loader in sector 0, so no regular GPT (or MBR) can be created. @jock are you saying that you didn't have this problem regarding both ROM and part. table using the same location on the disk?

@jock This is a good find! Kernel (using 'gpt' cmd line param) is happy with a backup GPT table at the end of the eMMC. So, this could be a solution for u-boot. Still the problem is the Amlogic u-boot which AFAIK doesn't have gpt support, so would need to re-build it, and then somehow properly reinstall. Probably easier would be then just replace it with the mainline u-boot. But I'll give it a try... see if can get at least the chainloaded u-boot recognize the GPT.

@hexdump No errors, just info that no valid part table found: U-Boot 2020.07-dirty (Oct 18 2021 - 02:27:09 +0200) hexdump-gxbb ... => mmc dev 2 switch to partitions #0, OK mmc2(part 0) is current device => mmc part ## Unknown partition table type 0 The 'gpt verify' fails too: => gpt verify mmc 2 No partition list provided - only basic check GUID Partition Table Header signature is wrong: 0x0 != 0x5452415020494645 gpt_verify_headers: *** ERROR: Invalid GPT *** Verify GPT: error! Observe gpt_verify_headers: int gpt_verify_headers(struct blk_desc *dev_desc, gpt_header *gpt_head, gpt_entry **gpt_pte) { /* * This function validates AND * fills in the GPT header and PTE */ if (is_gpt_valid(dev_desc, GPT_PRIMARY_PARTITION_TABLE_LBA, gpt_head, gpt_pte) != 1) { printf("%s: *** ERROR: Invalid GPT ***\n", // <-- this is the error I got __func__); return -1; } /* Free pte before allocating again */ free(*gpt_pte); if (is_gpt_valid(dev_desc, (dev_desc->lba - 1), // <-- Here it is checking the Backup GPT header gpt_head, gpt_pte) != 1) { printf("%s: *** ERROR: Invalid Backup GPT ***\n", __func__); return -1; } return 0; } So, this method doesn't even check the Backup GPT header if Primary is invalid (or missing in my case). I think as-is u-boot won't work with only the Backup GPT present. Sure, it could be patched, but this would require more coding then I'm willing to do. I do coding for living, and this exercise to get Armbian running from eMMC was kind of a distraction from work lol. Let's say I get this part working, then I would need to recompile/patch the original AML u-boot too - if I'm going to stick with the 'chainloading' design. The hard part would be integrate the recompiled AML u-boot into the original firmware, so I can burn it. The other option would be just try and use the mainline u-boot (no chainloading). Would be an interesting project, but a long shot. I think I'm just going to use the 'mmc read' method. Maybe I'll get back to this in future. Thanks for you assistance, I've enjoyed working with you.

<removed>

@hexdump i've enabled GPT in mailine u-boot,and I got 'gpt' command now, but it still doesn't see the partition: U-Boot 2020.07-dirty (Oct 18 2021 - 02:27:09 +0200) hexdump-gxbb ... => mmc dev 2 switch to partitions #0, OK mmc2(part 0) is current device => mmc part ## Unknown partition table type 0 The 'gpt verify' fails too: => gpt verify mmc 2 No partition list provided - only basic check GUID Partition Table Header signature is wrong: 0x0 != 0x5452415020494645 gpt_verify_headers: *** ERROR: Invalid GPT *** Verify GPT: error! I've checked the source code, and as far as I can tell, u-boot is only checking the primary GPT: int gpt_verify_headers(struct blk_desc *dev_desc, gpt_header *gpt_head, gpt_entry **gpt_pte) { /* * This function validates AND * fills in the GPT header and PTE */ if (is_gpt_valid(dev_desc, GPT_PRIMARY_PARTITION_TABLE_LBA, gpt_head, gpt_pte) != 1) { printf("%s: *** ERROR: Invalid GPT ***\n", __func__); return -1; } ... I couldn't even find definition for the backup GPT. Strange that it is working for you.

@hexdump thanks for the resources. Rebuilding the mainline uboot is not a problem, I already did it once using your instructions in the readme. But I'm not sure I will be able to rebuild the original AML uboot - which would need to have GPT support too.

@hexdump I've tested today the GPT scenario. I created a file, partitioned with 'gdisk', then I extracted the backup GPT records (last 33 LBA) and inserted at the end of the eMMC. After I rebooted linux recognized the 2 new partitions (/dev/mmcblk1p1 and p2). I created FAT on p1 and put a file there. Neither the AML uboot, nor the mainline uboot recognized the partition table. E.g.: on mailnine uboot: // EMMC: => mmc list mmc@70000: 0 mmc@72000: 1 (SD) mmc@74000: 2 (eMMC) => fatls mmc 2:1 ** No partition table - mmc 2 ** // SD works... => fatls mmc 1:1 dtb/ extlinux/ 709 aml_autoscript 0 aml_autoscript.zip 1536 armbian_first_run.txt.template 38518 boot.bmp 158 boot.ini 216810 config-5.9.0-arm-64 174 emmc_autoscript 9842151 initrd.img-5.9.0-arm-64 537 s905_autoscript 5794743 system.map-5.9.0-arm-64 609247 u-boot-s905 740080 u-boot-s905x2-s922 650183 u-boot-s905x-s912 9842215 uinitrd 28078592 zimage lost.dir/ android/ 521171 u-boot.ext .android_secure/ 0 .wipe_record 17 file(s), 5 dir(s) For you chromebook, did you compile uboot with some extra options enabled to get GPT backup working?

@usual user thanks, that is an interesting article you linked.

@usual user I run the test: [1] eMMC before change: # xxd -a -g 1 -l 512 /dev/mmcblk1 00000000: 1a e6 31 39 74 02 1f 27 93 be e3 cd 29 12 1b 71 ..19t..'....)..q 00000010: 40 41 4d 4c f0 bf 00 00 40 00 01 00 00 00 00 00 @AML....@....... 00000020: 00 00 00 00 40 00 00 00 00 02 00 00 60 00 00 00 ....@.......`... 00000030: 00 00 00 00 40 02 00 00 b0 0d 00 00 90 bf 00 00 ....@........... 00000040: 00 00 00 00 f0 0f 00 00 00 b0 00 00 00 00 00 00 ................ 00000050: fe 26 6e ba 84 e6 69 fc 6b 79 97 2c 0c 8a b3 15 .&n...i.ky.,.... 00000060: 13 70 39 86 a3 e4 b1 78 22 b4 9b b3 cf 65 88 9c .p9....x"....e.. 00000070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ * 000001f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ [2] write 0x55 0xaa to the last 2 bytes of 1st sector: echo -n -e '\x55\xaa' | dd if=/dev/stdin of=/dev/mmcblk1 bs=1 seek=$((512-2)) count=2 conv=notrunc [3] eMMC after change: # xxd -a -g 1 -l 512 /dev/mmcblk1 00000000: 1a e6 31 39 74 02 1f 27 93 be e3 cd 29 12 1b 71 ..19t..'....)..q 00000010: 40 41 4d 4c f0 bf 00 00 40 00 01 00 00 00 00 00 @AML....@....... 00000020: 00 00 00 00 40 00 00 00 00 02 00 00 60 00 00 00 ....@.......`... 00000030: 00 00 00 00 40 02 00 00 b0 0d 00 00 90 bf 00 00 ....@........... 00000040: 00 00 00 00 f0 0f 00 00 00 b0 00 00 00 00 00 00 ................ 00000050: fe 26 6e ba 84 e6 69 fc 6b 79 97 2c 0c 8a b3 15 .&n...i.ky.,.... 00000060: 13 70 39 86 a3 e4 b1 78 22 b4 9b b3 cf 65 88 9c .p9....x"....e.. 00000070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ * 000001f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa ..............U. [4] serial terminal: ~$ sudo -i root@buffy:~# stty -F /dev/ttyUSB0 cs8 -parenb cstopb crtscts root@buffy:~# picocom -b 115200 -d 8 -y n -p 1 -f n /dev/ttyUSB0 [5] reboot, and the serial shows: GXBB:BL1:08dafd:0a8993;FEAT:EDFC318C;POC:3;RCY:0; EMMC:0;READ:0;CHK:17A;SD:0;READ:0;CHK:F3;USB:8;LOOP:1; EMMC:0;READ:0;CHK:17A;SD:0;READ:0;CHK:F3;USB:8;LOOP:2; EMMC:0;READ:0;CHK:17A;SD:0;READ:0;CHK:F3;USB:8;LOOP:3; EMMC:0;READ:0;CHK:17A;SD:0;READ:0;CHK:F3;USB:8;LOOP:4; EMMC:0;READ:0;CHK:17A;SD:0;READ:0;CHK:F3;USB:8;...

@usual user > AFAIS you have inserted a populated partition table. Yes, that was my intention. > Maybe the boot firmware now changes the boot flow I doubt it does. AFAIK: the ROM uses secure-boot using 3 pieces BL1 (is in ROM), BL2 (in 1st sector on emmc), and BL3 is the u-boot. BL2 is also signed. With s905 Amlogic doesn't use regular partitions (e.g: 'mmc part' will give you "no partitions found", and 'fatload' etc. commands won't work either). Amlogic does maintain some kind of partition table. Based on the u-boot messages: mmc read lba=0x12000, blocks=0x2 mmc read lba=0x12002, blocks=0x2 mmc_read_partition_tbl: mmc read partition OK! eMMC/TSD partition table have been checked OK! gxb_p200_v1#mmc read 0x1200000 0x12000 0x400 gxb_p200_v1#md.b 0x1200000 0x400 01200000: 4d 50 54 00 30 31 2e 30 30 2e 30 30 00 00 00 00 MPT.01.00.00.... 01200010: 0e 00 00 00 ca 70 f2 de 62 6f 6f 74 6c 6f 61 64 .....p..bootload 01200020: 65 72 00 00 00 00 00 00 00 00 40 00 00 00 00 00 er........@..... 01200030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 01200040: 72 65 73 65 72 76 65 64 00 00 00 00 00 00 00 00 reserved........ 01200050: 00 00 00 04 00 00 00 00 00 00 40 02 00 00 00 00 ..........@..... 01200060: 00 00 00 00 00 00 00 00 63 61 63 68 65 00 00 00 ........cache... 01200070: 00 00 00 00 00 00 00 00 00 00 00 20 00 00 00 00 ........... .... 01200080: 00 00 c0 06 00 00 00 00 02 00 00 00 00 00 00 00 ................ 01200090: 65 6e 76 00 00 00 00 00 00 00 00 00 00 00 00 00 env............. 012000a0: 00 00 80 00 00 00 00 00 00 00 40 27 00 00 00 00 ..........@'.... 012000b0: 00 00 00 00 00 00 00 00 6c 6f 67 6f 00 00 00 00 ........logo.... 012000c0: 00 00 00 00 00 00 00 00 00 00 00 02 00 00 00 00 ................ 012000d0: 00 00 40 28 00 00 00 00 01 00 00 00 00 00 00 00 ..@(............ 012000e0: 72 65 63 6f 76 65 72 79 00 00 00 00 00 00 00 00 recovery........ 012000f0: 00 00 00 02 00 00 00 00 00 00 c0 2a 00 00 00 00 ...........*.... ... Amlogic made modifications to u-boot (they even have their own commands 'amlmmc' to read/write the emmc. So, I don't think they would or could modify the boot flow. > just add the boot signature "55AA" to the last two bytes of the sector OK, I will try.

@hexdump I'm using this one: https://github.com/natinusala/linux-amlogic-toolkit I've tried two others, but only this one worked. (Has the script updated). Yes, I have to ground the emmc clock pin while powering up. You will need to add a line to /etc/udev/rules.d: SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", ATTR{idVendor}=="1b8e", ATTR{idProduct}=="c003", MODE:="0666", SYMLINK+="worldcup". Plugin OTG USB, Short the pin, power-up, remove the short, and lsusb will show a new Amlogic device. 1st time you need to let the tool unpack your firmware, after this just exec the 'flash' script. Here is the last part of the dbg log I still have on my screen: Writing system partition Command -> /home/pista/amlburn/linux-amlogic-toolkit-master/bin/aml-linux-usb-burn/tools/update 2>/dev/null partition system /home/pista/amlburn/linux-amlogic-toolkit-master/output/image/system.PARTITION - Results --------------------------------------------------- [update]sparse format detected file size is 0x3e01502c AmlUsbTplCmd = download store system sparse 0x3e01502c rettemp = 1 buffer = download store system sparse 0x3e01502c AmlUsbReadStatus retusb = 1 Downloading.... [update]Cost time 80Sec [update]Transfer size 0x3e01502cB(992MB) AmlUsbBulkCmd[download get_status] [update]mwrite success ------------------------------------------------------------- [OK] Done

@hexdump Yes, I've learned about this option from your post in an other thread. Also people from the NXP processor forum mentioned this. It was the one option I didn't try. I guess it would be worth... shouldn't be much work and there is no chance to brick again. @TonyMac32 has git of the old Amlogic u-boot, and I see the gpt command does exist in this version, but it is not available on my TV box, so the question is whether GPT support is enabled. I probably try it later today...

@hexdump I didn't touch the bootloader, it is the original from the TV box. I only inserted the 72 bytes at the end of the 1st block (which was originally empty). It seems it is not possible to change the 1st block at all, even if you just modify the empty space. My guess is that when ROM is checking whether emmc has a valid BL it reads the whole 512 bytes (instead of just the length of BL) and does some CRC, or other validation, so even changing a single 00 byte will cause ROM to reject the bootloader. I even tried twice just to make sure I didn't make a mistake, I bricked both times. (Thankfully the Linux version of the AML USB burning tool is working very well). P.S.: yes it didn't start, I got that string from ROM (starting with "BL1" repeating in a loop.

@hexdump @usual user OK, it doesn't work. I bricked the box twice It is strange, because it should work, but doesn't. I've created a file with 2 partitions (boot, root): fallocate -l 200M tst.img fdisk ... // file systems not really needed for this... kpartx -a -v tst.img mkfs.vfat -n BOOT /dev/mapper/loop0p1 mkfs.ext4 /dev/mapper/loop0p2 e2label /dev/mapper/loop0p2 ROOT kpartx -d disk.image xxd -a -g 1 -l 512 tst.img 00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ * 000001b0: 00 00 00 00 00 00 00 00 2d bd 6b 1f 00 00 80 8a ........-.k..... 000001c0: 09 82 0b 88 13 b5 00 00 20 00 00 80 0c 00 00 88 ........ ....... 000001d0: 14 b5 83 27 e9 be 00 80 2c 00 00 60 be 00 00 00 ...'....,..`.... 000001e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000001f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa ..............U. // extract last 72 bytes of the 1 sector dd if=tst.img of=tbl.img bs=1 skip=440 count=72 xxd -a -g 1 tbl.img 00000000: 2d bd 6b 1f 00 00 80 8a 09 82 0b 88 13 b5 00 00 -.k............. 00000010: 20 00 00 80 0c 00 00 88 14 b5 83 27 e9 be 00 80 ..........'.... 00000020: 2c 00 00 60 be 00 00 00 00 00 00 00 00 00 00 00 ,..`............ 00000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000040: 00 00 00 00 00 00 55 aa ......U. // write to the end of the 1st sector on eMMC dd if=tbl.img of=/dev/mmcblk1 bs=1 seek=440 count=72 conv=notrunc xxd -a -g 1 -l 512 /dev/mmcblk1 00000000: 1a e6 31 39 74 02 1f 27 93 be e3 cd 29 12 1b 71 ..19t..'....)..q 00000010: 40 41 4d 4c f0 bf 00 00 40 00 01 00 00 00 00 00 @AML....@....... 00000020: 00 00 00 00 40 00 00 00 00 02 00 00 60 00 00 00 ....@.......`... 00000030: 00 00 00 00 40 02 00 00 b0 0d 00 00 90 bf 00 00 ....@........... 00000040: 00 00 00 00 f0 0f 00 00 00 b0 00 00 00 00 00 00 ................ 00000050: fe 26 6e ba 84 e6 69 fc 6b 79 97 2c 0c 8a b3 15 .&n...i.ky.,.... 00000060: 13 70 39 86 a3 e4 b1 78 22 b4 9b b3 cf 65 88 9c .p9....x"....e.. 00000070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ * 000001b0: 00 00 00 00 00 00 00 00 2d bd 6b 1f 00 00 80 8a ........-.k..... 000001c0: 09 82 0b 88 13 b5 00 00 20 00 00 80 0c 00 00 88 ........ ....... 000001d0: 14 b5 83 27 e9 be 00 80 2c 00 00 60 be 00 00 00 ...'....,..`.... 000001e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000001f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa ..............U. Hex dump shows BL2 is still intact, and tbl.img has been written to a place which was originally empty. So, unless I'm missing something it looks like ROM is doing some extra checking that the 1st sector has not been tampered with, or something. Well, it was a nice idea. I guess I use my method, it is more complex, but it works.