Hi
I want to upgrade uboot partition(EBT) by recovery mode,but I can not found this partition in /dev/block/platform/sdhci-tegra.3/by-name.
So how do I show all partition in dev/block/platform/sdhci-tegra.3/by-name?
Thanks
Hi NVIDIA
Could you please help give me any advice?
Thanks
For reference, I am looking at R21.6 (R21.5 will be nearly identical).
If you look at partition labels on a running TK1 by this command you’ll see there is nothing directly labeled EBT:
sudo gdisk -l /dev/mmcblk0
GPT fdisk (gdisk) version 0.8.8
Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: present
Found valid GPT with protective MBR; using GPT.
Disk /dev/mmcblk0: 30777344 sectors, 14.7 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): A81E231F-7B1C-C564-1473-5AC55E4B7963
Partition table holds up to 9 entries
First usable sector is 94208, last usable sector is 30773247
Partitions will be aligned on 2048-sector boundaries
Total free space is 0 sectors (0 bytes)
Number Start (sector) End (sector) Size Code Name
1 94208 29954047 14.2 GiB 0700 APP
2 29954048 29962239 4.0 MiB 0700 DTB
3 29962240 30093311 64.0 MiB 0700 EFI
4 30093312 30101503 4.0 MiB 0700 USP
5 30101504 30109695 4.0 MiB 0700 TP1
6 30109696 30117887 4.0 MiB 0700 TP2
7 30117888 30126079 4.0 MiB 0700 TP3
8 30126080 30130175 2.0 MiB 0700 WB0
9 30130176 30773247 314.0 MiB 0700 UDA
Even so I see it in flash logs:
[ EBT] UH 8192 16383 4.0MiB u-boot.bin
This implies that either EBT is an abstract alias not used as a partition label, or else it is being embedded with other content in a partition not using this label directly.
Should there just be a name/alias difference, the flash log does offer a clue: The size is 4.0MiB, which is fairly small, and leaves these as possible partitions:
2 29954048 29962239 4.0 MiB 0700 DTB
4 30093312 30101503 4.0 MiB 0700 USP
5 30101504 30109695 4.0 MiB 0700 TP1
6 30109696 30117887 4.0 MiB 0700 TP2
7 30117888 30126079 4.0 MiB 0700 TP3
Later the flash log says this:
sending file: u-boot.bin
- 439776/439776 bytes sent
u-boot.bin sent successfully
…the size is not an exact match to the partition, so you are not guaranteed where within the 4.0 MiB the file is located (usually at the start if it is the only data, and the rest would be NULL bytes).
Because I’ve flashed my “bootloader/” subdirectory has this file and size is valid…it matches 439776 bytes.
I copied each of these partitions inside of an empty temp directory:
sudo -s
dd if=/dev/mmcblk0p2 of=p2.bin bs=512
dd if=/dev/mmcblk0p4 of=p4.bin bs=512
dd if=/dev/mmcblk0p5 of=p5.bin bs=512
dd if=/dev/mmcblk0p6 of=p6.bin bs=512
dd if=/dev/mmcblk0p7 of=p7.bin bs=512
exit
If you run “strings u-boot.bin” you will see a number of possibly unique text tokens which might identify this partition. Device tree content is not likely to be unique among those partitions. A candidate string to search for is “Cannot find console”. I search in that directory as follows:
egrep 'Cannot find console' *.bin
My conclusion is that u-boot.bin is not in any obvious partition. It does happen though that partitions are not the only content of a disk. There is data at the start of the disk before partitions start. You’ll see the first partition starts at sector 94208, and with a sector size of 512 bytes, this means you can copy this content via:
sudo dd if=/dev/mmcblk0 of=blk0.meta.bin bs=512 count=94207
When I do the same “grep” on blk0.meta.bin I see a hit.
If I go into u-boot.bin with a hex editor (I’m using ghex in this case) the “C” of “Cannot” starts at byte offset 0x002ae3. So now I check the byte offset of my blk0.meta.bin, and see it starts at byte offset 0x402ae3. The u-boot.bin file starts at offset 0x402ae3 minus 0x002ae3 (0x400000, or base 10 4194304).
To verify I’ll match a dd operation output to the bin file. Note that 4194304/512 is exactly divisible by the block size of 512…or 8192 base 10). Also note that the original “bootloader/u-boot.bin” file size is 439776:
sudo dd if=/dev/mmcblk0 of=extract_uboot.bin bs=1 skip=4194304 count=439776
See if they match:
sha1sum extract_uboot.bin
sha1sum bootloader/u-boot.bin
…for my R21.6 I get a match:
07b7393ddfd16b67bf4a667bcea4972c9d6fc7b0 extract_uboot.bin
07b7393ddfd16b67bf4a667bcea4972c9d6fc7b0 u-boot.bin
This is where u-boot.bin is…it isn’t in a partition, it was part of building the metadata at the start of a GPT partition scheme. If you have another u-boot binary of exactly the same size you could use dd to this location to write the new bootloader in. If you have an alternate u-boot.bin which is smaller than this, then you could pad the end with NULL bytes and write it to this offset. If your u-boot replacement is longer, then you would have to understand the structure of the metadata and probably rebuild the entire set of bytes leading up to the first partition sector offset.
Where are you getting “dev/block/platform/sdhci-tegra.3/by-name”? Knowing this might simplify a practical solution.
Incidentally, if you use flash.sh, then this will all be built for you if you were to use your own u-boot.bin. The most reliable method would probably be to clone your rootfs partition, and then flash “reusing” this clone (but with the u-boot.bin binary replaced by yours. You might need to back up the existing “bootloader/ardbeg/u-boot.bin”, put yours in its place, and expect it to propagate to “bootloader/u-boot.bin” (or just put it in both locations and sha1sum to make sure you got the right one after flash).
Hint: Most binary data in a partition is written to block/sector size multiples, and any extra space needed as padding at the end of the data (in order to make it an exact block size multiple) is usually NULL. There are some underlying commands when flash.sh runs which you will see actually specify NULL byte padding.
Hi linuxdev
Thanks a lot for your answer.
EBT should be an abstract alias.But uboot partition have not a block node in dev/block(eg.dev/block/mmcblk0p1).
The jtk1’s partition seems to create by nvflash tool.So some partitions not list in dev/block.
So do you have any method to list all partition in dev/block?
Look forward to your reply.
Thanks
My understanding is that there is no distinct EBT (U-Boot) partition, that this is a subset of the metadata at the start of the disk (it is part of mmcblk0, not mmcblk0p#). All block device partitions are shown in “lsblk” (with the exception that the container of the block devices is “/dev/mmcblk0” and is itself a block device). All partitions are block devices (e.g., mmcblk0p1), but not all block devices (e.g., mmcblk0) are partitions.
If this were x86 I’d say everything starts in the master boot record which is a reserved space at the beginning of the disk (this isn’t technically absolutely correct…there are differences between GPT and old style BIOS partitions, and of course a Jetson doesn’t have a BIOS or UEFI in the usual hardware sense).
Considering this is not a partition, and that a Jetson does not have a BIOS or UEFI, you would have to write to the metadata area of the disk, not to a partition. Someone from NVIDIA will have to comment, but I do not believe it is possible to view U-Boot’s location as a partition…it has the EBT alias, but this seems to be used as information on what to combine in order to flash the metadata at the disk start.
There is a section in the official Documentation of R21.5 which explains relative to building a custom U-Boot and then flashing it to EBT…here is an edited excerpt:
cp <uboot_src_dir>/u-boot/u-boot-dtb-tegra.bin <your_L4T_root>/Linux_for_Tegra/bootloader/<platform>/u-boot.bin
sudo ./flash.sh -k EBT jetson-tk1 mmcblk0p1
(https://developer.nvidia.com/linux-tegra-r215)
I do not know the internals of nvflash although on many occasions this would have been very useful. Is there something you are trying to do which flash.sh and nvflash won’t work with?
Hi all,
In the past I did some tinkering with NVIDIA’s flash.sh mega-script in order to learn about the flashing process and to understand its inner workings.
During the flashing routine, a tool is called which is called mkgpt, which, according to the name, creates the GPT table for the partition layout.
mkgpt help prompt tells us the following
Usage: ./tools/mkgpt [options] [target device]
where
<options> are:
-a|--alternategpt <Alternate GPT configuration name>
-b|--bootpartsize <total boot partition size>
-c|--configfile <partition table file path>
-d|--decode <GPT image file>
-e|--eraseblksize <erase block size>
-l|--lba <partition name>
-n|--nblocks <partition name>
-p|--primarygpt <primary GPT configuration name>
-r|--read
-s|--sectorsize <FileSystem buffer size>
-t|--totaldevicesize <total device size>
-v|--visiblepartname <Visible partition exclusibe start>
-B|--Blocksize <Device Sector Size>
-L|--LastLBA
-P|--PrimaryGPTName <Primary GPT output file path>
-S|--SecondaryGPTName <Secondary GPT output file path>
-V|--Verbose
<target device> is:
target device such as /dev/sd? or /dev/loop?
I think that EBT is an actual partition but the option -v is used to hide it. So it should be what you’re looking for. You could try forcing its value inside the flash.sh script (or see if somehow it can be passed externally).
I’ve been working with my own flashing scripts for a while now, but by checking L4T 21.6 flash.sh script I see this:
if [ ! -z "${bootpartsize}" -a ! -z "${emmcsize}" ]; then
echo "creating gpt(${localpptfile})... ";
MKGPTOPTS="-c ${localcfgfile} -P ${localpptfile} ";
MKGPTOPTS+="-t ${emmcsize} -b ${bootpartsize} -s 4KiB ";
MKGPTOPTS+="-a GPT -v GP1 ";
MKGPTOPTS+="-V ${MKGPTCMD} ";
./mkgpt ${MKGPTOPTS};
chkerr "creating gpt(${localpptfile}) failed.";
fi;
I think that if you change GP1 to the partition before EBT, you might be able to have Linux pick it up. Right now I’m flashing my devices with a custom partition scheme (I removed some unnecessary partitions that were in the original flashing scripts), and I’ve changed the -v option, but never to make the EBT partition visibile. It should work if EBT is a partition like all the others though.
However, note that this will break all the numbering of the partitions you already have (i.e. the X in /dev/mmcblk0pX), so the board might not boot anymore since extlinux.conf (and u-boot) require a specific partition to be specified. You would need to edit extlinux.conf accordingly and also interact with u-boot through the serial console to point it towards the right partition.
Regarding the fact that EBT is an actual partition, it’s listed along the other “standard” partitions in the gnu_linux_fastboot_emmc_full.cfg file, which specifies partitions and their sizes.
Below I’ve pasted the file, you can see that GP1 is right before APP, which is the main partition where the rootfs is copied to in the standard scenario.
[device]
type=sdmmc
instance=3
[partition]
name=BCT
id=2
type=boot_config_table
allocation_policy=sequential
filesystem_type=basic
size=2097152 #BCTSIZE
file_system_attribute=0
partition_attribute=0
allocation_attribute=8
percent_reserved=0
[partition]
name=PPT
id=3
type=data
allocation_policy=sequential
filesystem_type=basic
size=8388608 #PPTSIZE
file_system_attribute=0
partition_attribute=0
allocation_attribute=8
percent_reserved=0
#filename=ppt.img
[partition]
name=PT
id=4
type=partition_table
allocation_policy=sequential
filesystem_type=basic
size=2097152
file_system_attribute=0
partition_attribute=0
allocation_attribute=8
percent_reserved=0
[partition]
name=EBT
id=5
type=bootloader
allocation_policy=sequential
filesystem_type=basic
size=4194304
file_system_attribute=0
partition_attribute=0
allocation_attribute=8
percent_reserved=0
filename=fastboot.bin
[partition]
name=LNX
id=6
type=data
allocation_policy=sequential
filesystem_type=basic
size=16777216
file_system_attribute=0
partition_attribute=0
allocation_attribute=8
percent_reserved=0
filename=boot.img
[partition]
name=SOS
id=7
type=data
allocation_policy=sequential
filesystem_type=basic
size=6291456
file_system_attribute=0
partition_attribute=0
allocation_attribute=8
percent_reserved=0
#filename=recovery.img
[partition]
name=NVC
id=8
type=data #TEGRABOOT
allocation_policy=sequential
filesystem_type=basic
size=2097152
file_system_attribute=0
partition_attribute=0
allocation_attribute=8
percent_reserved=0
#filename=nvtboot.bin
[partition]
name=MPB
id=9
type=data #MTSPREBOOT
allocation_policy=sequential
filesystem_type=basic
size=6291456
file_system_attribute=0
partition_attribute=0
allocation_attribute=8
percent_reserved=0
#filename=mts_preboot_si
[partition]
name=MBP
id=10
type=data #MTSBOOTPACK
allocation_policy=sequential
filesystem_type=basic
size=6291456
file_system_attribute=0
partition_attribute=0
allocation_attribute=8
percent_reserved=0
#filename=mts_si
[partition]
name=GP1
id=11
type=GP1
allocation_policy=sequential
filesystem_type=basic
size=2097152
file_system_attribute=0
partition_attribute=0
allocation_attribute=8
percent_reserved=0
[partition]
name=APP
id=12
type=data
allocation_policy=sequential
filesystem_type=basic
size=1073741824
file_system_attribute=0
partition_attribute=0
allocation_attribute=8
percent_reserved=0
filename=system.img
[partition]
name=DTB
id=13
type=data
allocation_policy=sequential
filesystem_type=basic
size=4194304
file_system_attribute=0
partition_attribute=0
allocation_attribute=8
percent_reserved=0
#filename=tegra.dtb
[partition]
name=EFI
id=14
type=data
allocation_policy=sequential
filesystem_type=basic
size=67108864 #EFISIZE
file_system_attribute=0
partition_attribute=0
allocation_attribute=8
percent_reserved=0
#filename=efi.img
[partition]
name=USP
id=15
type=data
allocation_policy=sequential
filesystem_type=basic
size=4194304
file_system_attribute=0
partition_attribute=0
allocation_attribute=8
percent_reserved=0
[partition]
name=TP1
id=16
type=data
allocation_policy=sequential
filesystem_type=basic
size=4194304
file_system_attribute=0
partition_attribute=0
allocation_attribute=8
percent_reserved=0
[partition]
name=TP2
id=17
type=data
allocation_policy=sequential
filesystem_type=basic
size=4194304
file_system_attribute=0
partition_attribute=0
allocation_attribute=8
percent_reserved=0
[partition]
name=TP3
id=18
type=data
allocation_policy=sequential
filesystem_type=basic
size=4194304
file_system_attribute=0
partition_attribute=0
allocation_attribute=8
percent_reserved=0
[partition]
name=WB0
id=19
type=data #WB0BOOT
allocation_policy=sequential
filesystem_type=basic
size=2097152
file_system_attribute=0
partition_attribute=0
allocation_attribute=8
percent_reserved=0
#filename=nvtbootwb0.bin
[partition]
name=UDA
id=20
type=data
allocation_policy=sequential
filesystem_type=basic
size=2097152
file_system_attribute=0
partition_attribute=0
allocation_attribute=0x808
percent_reserved=0
[partition]
name=GPT
id=21
type=GPT
allocation_policy=sequential
filesystem_type=basic
size=0xFFFFFFFFFFFFFFFF
file_system_attribute=0
partition_attribute=0
allocation_attribute=8
percent_reserved=0
#filename=spt.img
Hope this helps, let me know if something wasn’t clear or what you plan to try!