pista

  • Posts

    22
  • Joined

  • Last visited

pista's Achievements

  1. @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.
  2. @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.
  3. @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.
  4. @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.
  5. @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?
  6. @usual user thanks, that is an interesting article you linked.
  7. @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;...
  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.
  9. @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
  10. @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...
  11. @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.
  12. @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.
  13. @hexdump I'm now intrigued... I was about to put the PCB back to the box, but I think I will do some experiments over the weekend. I do see that eMMC has BL2 (or is it BL3) at the beginning of the 1st block - total 111 bytes. Then nothing until 4096: root@arm-64:~# hexdump -C -n $((4096+64)) /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 |................| * 00001000 02 00 00 14 08 b2 00 d9 f4 03 00 aa f5 03 01 aa |................| 00001010 a0 00 38 d5 11 22 00 94 a0 02 00 b4 20 bf 04 10 |..8.."...... ...| 00001020 00 c0 18 d5 00 10 38 d5 00 00 74 b2 00 10 18 d5 |......8...t.....| 00001030 df 3f 03 d5 e0 01 00 58 01 02 00 58 6c 22 00 94 |.?.....X...Xl"..| 00001040 So... [updated based on info from Mr. usual user] 0 100 200 300 400 500 600 |-----|-----|-----|-----|-----|-----| | | | | 112 (BL2) 440 512 (72 bytes) 0x70 0x1B8 0x1FF It looks like the problem with S905 is not that the part. table overwrites the bootloader, but that the partitioning software (fdisk) wipes the space before the part. table (446 bytes). In theory it should be possible to just create the partitions and then restore the 1st 400 bytes. I think I'll try on mounted disk-image first.