PROCESSOR-SDK-AM62X: SK AM62X EVK - Configuring eMMC as if it was erased (factory fresh). Some questions about mmc hwpartion, mmc partconf, gpt and related commands

Hi Robert,

I am routing your query to our U-Boot expert for comments.

Thanks Bin!

I can create a partition table using fdisk from linux (booting from SD card). Which won't be available on the custom board.

And I think if I load ram with kernel images,rfs,dtb I can use bootm, then perhaps use Linux to correct the partition.

But the basic rfs image with the SDK is  629145600 bytes. And that pushes it to conflict with the running images. So that puts pain to that idea.

=> gpt repair mmc 0
Repairing GPT: error!

=> gpt repair mmc 0 1
Repairing GPT: error!
=> gpt repair mmc 0 2
Repairing GPT: error!
=> echo $partitions
uuid_disk=e1402411-be20-4dc6-a229-915e6bd66f33;name=rootfs,start=16384,size=15539695,uuid=e7dbd504-c47a-493d-a1d4-aa34686b4b5b
=> gpt write mmc 0 $partitions
Writing GPT: error!
=>

I'm not sure if your able to help at this point I reviewed the JDEC spec, I'll continue to review these and other documents. 

Regards,

Robert

Note, I have tested 0x400000 boot 2 backup to boot 1. I had seen another thread indicating ROM code did not support detection and jump to 0x400000 raw tiboot3.bin.

I think from version 7 of the SDK. So it is good news it is supported with the SoC I have now.

Hi Hong,

Yes, I tested RAW boot backup on boot 1 by erasing a few bytes from raw boot 0 - this works. 

I wonder how others are partitioning flash if all they have is ethernet backup mode to program their flash (outside of JTAG).

I would think u-boot => GPT calls easily

If uncommented this section of uEnv.txt (should) erase the SK_AM623B flash, then create two partitions past the RAW section (starting at 0x800000), realize I reused the rootfs name, but just creating the first partition results in an GPT error.

Walking through these commands fails at the gpt write mmc 0 $partitions step. 

## Erase the device, prep for future writes.
#cmd_1a=mmc erase 0 31080414
#cmd_1b=setenv uuid_gpt_disk e1402411-be20-4dc6-a229-915e6bd66f33
#cmd_1c=setenv uuid_gpt_rootfs e7dbd504-c47a-493d-a1d4-aa34686b4b5b
#cmd_1d=setenv partitions "uuid_disk=${uuid_gpt_disk};name=rootfs,start=16384,size=15539695,uuid=${uuid_gpt_rootfs}"
#cmd_1e=gpt write mmc 0 $partitions
#cmd_1f=emmc part
## See what we have

#cmd_1g=setenv uuid_gpt_rootfs 93e4c649-cb27-4c27-ab7f-eb65a9ec348c
#cmd_1h=setenv partitions "uuid_disk=${uuid_gpt_disk};name=rootfs,start=15540719,size=15539695,uuid=${uuid_gpt_rootfs}"
#cmd_1i=gpt write mmc 0 $partitions
#cmd_1j=emmc part
## See what we have

Have you used gpt to perform these tasks?, I wonder if I'm missing some part of flash - the bdinfo, and last sector from prior (linux based partitioning vi SD card boot) showed that as the correct last partition.

But I'll take another look.

Robert

I've looked at this one - it looks like you create a binary file using dd, then partition it using gdisk, then from the image extract the first 64 records with the partition table.

But then this needs to be written where? It's not clear, and it seems the end of flash part makes the most sense.

To determine where at the end of flash to put it, I looked at the flash (extracted to RAM) and looked through the dump to find some non zero bytes. Then attempted to pull the 'custom' partition table extracted from the gdisk creation and place it in the same location the other flash partition table had been (I had erased it)

Steps:

Calculating partition size as:
0x404000 - end of flash 0x1da4000 BLKs (I beleive I don't include the boot0, boot1 space)
Total: 19a0000 Blks or ~13.7GB

 Virtual Disk being partitioned Just needs to be bigger than that..
 @bs=x10000 (65K) thats 19a blk count (410) to get to bytes x512

$ dd if=/dev/zero of=disk2.img bs=65K count=209920
209920+0 records in
209920+0 records out
13972275200 bytes (14 GB, 13 GiB) copied, 5.80583 s, 2.4 GB/s

$ gdisk disk2.img
GPT fdisk (gdisk) version 1.0.8

Partition table scan:
  MBR: not present
  BSD: not present
  APM: not present
  GPT: not present

Creating new GPT entries in memory.

Command (? for help): n
Partition number (1-128, default 1):
First sector (34-27289566, default = 2048) or {+-}size{KMGTP}:
Last sector (2048-27289566, default = 27289566) or {+-}size{KMGTP}:
Current type is 8300 (Linux filesystem)
Hex code or GUID (L to show codes, Enter = 8300):
Changed type of partition to 'Linux filesystem'

Command (? for help): w

Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING
PARTITIONS!!

Do you want to proceed? (Y/N): y
OK; writing new GUID partition table (GPT) to disk2.img.
Warning: The kernel is still using the old partition table.
The new table will be used at the next reboot or after you
run partprobe(8) or kpartx(8)
The operation has completed successfull

Then extract the GPT table for copy to the target flash:

$ dd if=disk2.img of=gpt2.img count=64
64+0 records in
64+0 records out
32768 bytes (33 kB, 32 KiB) copied, 0.00063716 s, 51.4 MB/s

This is where I run into problems on placement.
It looks like flash ends at 0x1da4000, so I should move back 64x512 from this point
(or 40 blocks) thus: 1DA3FC0 blocks from begining of flash. 
.. Place GPT table here?

The next step if I get this to work would be:

=> help ext4write
ext4write - create a file in the root directory

Usage:
ext4write <interface> <dev[:part]> <addr> <absolute filename path>
    [sizebytes] [file offset]
    - create a file in / directory
    
I'm also hitting a stumbling block with RFS file size when 
dhcp rootfs.ext4.emmc (the eMMC image I want on the target) - it's too big.
.. Looking to compress this again instead of following SDK instructions for USB-DFU.

Thoughts? Is this the correct path?

But then circled back to the original post, and did additional comparisons and see that

#cmd_1d=setenv partitions "uuid_disk=${uuid_gpt_disk};name=rootfs,start=16384,size=15539695,uuid=${uuid_gpt_rootfs}"

if I use K, and MiB and other units it works, so there is a problem with the start/size - these should be in blocks, but they fail.

ie.: 

fails:

"uuid_disk=e1402411-be20-4dc6-a229-915e6bd66f33;name=rootfs,start=16384,size=15539695,uuid=e7dbd504-c47a-493d-a1d4-aa34686b4b5b"

works:

"uuid_disk=e1402411-be20-4dc6-a229-915e6bd66f33;name=rootfs,start=500K,size=12MiB,uuid=e7dbd504-c47a-493d-a1d4-aa34686b4b5b"

This is good and all, but when working with RAW eMMC boot modes this overwrites my boot0 location with partition table information.

• I think perhaps I can create a fake one off line: http://rockchip.wikidot.com/partitions
• But then need to swap the record order I think for this to make sense at the end of flash (backup partition table space).
• -- Not completely sure on how I'll swap things yet. Probably a script (review of both https://github.com/theojulienne/u-boot/blob/master/doc/README.gpt and http://rockchip.wikidot.com/partitions).
• Note on RAW boot0 and boot1 test results if one is corrupted the other works can be found here: https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1336002/am623-the-boot1-backup-partition-for-raw-mode-is-located-at-0x400000-per-trm-this-seems-to-lie-within-boot0-space-per-sdk

Perhaps I do the partitions first, the write the boot0,boot1 over the first partition table - this assumes this instruction creates the backup gpt data at top of flash as well. If that's true then I may be done. As long as later when running Linux or some other process doesn't break the partition table.

And a point here is - partition tables are redundant for a reason, loose both and I'm not sure u-boot can find the images. If that's true I wonder why boot0/boot1 in raw are using the same space the partition tables are using. Or, am i misunderstanding something here?

=> setenv uuid_gpt_disk 9fd6884f-729a-48fe-a935-a343a6ebde86
=> setenv uuid_gpt_boot 3e59e9d0-f97f-4282-af18-4a70c4c9ab59
=> setenv uuid_gpt_rootfs 2906b911-83bd-4503-8d68-1a68d78067fe
=> setenv partitions "uuid_disk=${uuid_gpt_disk};name=boot,start=2MiB,size=128MiB,uuid=${uuid_gpt_boot};name=rootfs,start=130MiB,size=-,uuid=${uuid_gpt_rootfs}"
=> gpt write mmc 0 ${partitions}
Writing GPT: success!
=> reset
resetting ...