I created a FIT image containing the Kernel, ramdisk and the Device Tree Blob to start Linux. I can boot this fine without Secure Boot.
Previously I could successfully sign and verify the authenticity of just the uImage of the kernel using the guide at
but this procedure doesn't seem to work with a FIT image. Is it possible to sign the FIT image as a whole? Else I would just fall back to U-Boot verification, because the HAB procedure is very time-consuming.
Solved! Go to Solution.
@BiyongSUN I could solve it now using this patch
I wonder why this was not enabled by default yet. Is there a good reason?
@Zhiming_LiuThank you for the reply! Is there another way to authenticate the ramdisk and device tree blob then? We need this for our current USB update, because it is not covered by Android Verified Boot. HAB doesn't check if the ramdisk is signed. The secure boot mechanism for the mainline U-Boot uses signing with mkimage. Can I use this mechanism with the uboot-imx fork as well? Because when you set CONFIG_SECURE_BOOT in the fork, it uses HAB instead.
Problem is that I can't find a good guide on how to sign a FIT image using HAB. The guide mentioned above only covers a bootloader FIT image and not a kernel FIT image.
Hi @jclsn
__weak void __noreturn jump_to_image_no_args(struct spl_image_info *spl_image)
{
typedef void __noreturn (*image_entry_noargs_t)(void);
uint32_t offset;
image_entry_noargs_t image_entry =
(image_entry_noargs_t)(unsigned long)spl_image->entry_point;
debug("image entry point: 0x%lX\n", spl_image->entry_point);
if (spl_image->flags & SPL_FIT_FOUND) {
image_entry();
} else {
/*
* HAB looks for the CSF at the end of the authenticated
* data therefore, we need to subtract the size of the
* CSF from the actual filesize
*/
offset = spl_image->size - CONFIG_CSF_SIZE;
if (!imx_hab_authenticate_image(spl_image->load_addr,
offset + IVT_SIZE +
CSF_PAD_SIZE, offset)) {
image_entry();
} else {
panic("spl: ERROR: image authentication fail\n");
}
}
}
Mybe I find some useful message.from the code in jump_to_image_no_args, when you use fit image, there will be no hab authentication in i.MX
Hi @Zhiming_Liu,
sorry but I don't understand your reply. Do you want me to change the U-Boot source code so it prints debug messages? If yes, where?
Thank you
Is it possible to sign the FIT image as a whole? Else I would just fall back to U-Boot verification, because the HAB procedure is very time-consuming.
u-boot/arch/arm/mach-imx/hab.c
static ulong get_image_ivt_offset(ulong img_addr)
{
const void *buf;
buf = map_sysmem(img_addr, 0);
switch (genimg_get_format(buf)) {
#if CONFIG_IS_ENABLED(LEGACY_IMAGE_FORMAT)
case IMAGE_FORMAT_LEGACY:
return (image_get_image_size((image_header_t *)img_addr)
+ 0x1000 - 1) & ~(0x1000 - 1);
#endif
#if IMAGE_ENABLE_FIT
case IMAGE_FORMAT_FIT:
return (fit_get_size(buf) + 0x1000 - 1) & ~(0x1000 - 1);
#endif
default:
return 0;
}
}
static int do_authenticate_image(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
{
ulong addr, length, ivt_offset;
int rcode = 0;
if (argc < 3)
return CMD_RET_USAGE;
addr = simple_strtoul(argv[1], NULL, 16);
length = simple_strtoul(argv[2], NULL, 16);
if (argc == 3)
ivt_offset = get_image_ivt_offset(addr);
else
ivt_offset = simple_strtoul(argv[3], NULL, 16);
rcode = imx_hab_authenticate_image(addr, length, ivt_offset);
if (rcode == 0)
rcode = CMD_RET_SUCCESS;
else
rcode = CMD_RET_FAILURE;
return rcode;
}
Yes,mx8m_secure_boot.txt IS the guide to sign data including fit image.
Well, that is what I tried, but I am geting and "Invalid IVT header" error, when I try to boot the FIT image.
I should probably mention that I am talking about a FIT image container the Linux Kernel + ramdisk + .dtb.
I am assuming that U-Boot loads the Kernel, ramdisk and .dtb file into their corresponding memory regions and then tries to authenticate them. This would mean that I would have to sign each individual components first and then create the FIT image. But then there would be no reason to create the FIT image, because I want U-Boot to authenticate the image when it is called via bootm. If I sign the ramdisk and .dtb individually I would have to authenticate them with hab_auth_img before booting the Kernel with bootm and I would think that this could easily be compromised by changing the boot script.
"I should probably mention that I am talking about a FIT image container the Linux Kernel + ramdisk + .dtb."
we know what is fit image.
What is different between Image, zImage, fit image, Hamlet of William Shakespeare in this case?
3.1 Padding the image ---------------------- The zImage must be padded to the next boundary address (0x1000), for instance if the image size is 0x649920 it must be padded to 0x64A000. The tool objcopy can be used for padding the image. - Pad the zImage: $ objcopy -I binary -O binary --pad-to 0x64A000 --gap-fill=0x00 \ zImage zImage_pad.bin 3.2 Generating Image Vector Table ---------------------------------- The HAB code requires an Image Vector Table (IVT) for determining the image length and the CSF location. Since zImage does not include an IVT this has to be manually created and appended to the end of the padded zImage, the script genIVT.pl in script_examples directory can be used as reference. - Generate IVT: $ genIVT.pl Note: The load Address may change depending on the device. - Append the ivt.bin at the end of the padded Image: $ cat zImage_pad.bin ivt.bin > zImage_pad_ivt.bin
------- +-----------------------------+ <-- *load_address ^ | | | | | | | | | | | | | Image | Signed | | | Data | | | | | | | +-----------------------------+ | | Padding Next Boundary | | +-----------------------------+ <-- *ivt v | Image Vector Table | ------- +-----------------------------+ <-- *csf | | | Command Sequence File (CSF) | | | +-----------------------------+ | Padding (optional) | +-----------------------------+
------- +-----------------------------+ <-- *load_address ^ | | | | | | | | | | | | | zImage | Signed | | | Data | | | | | | | +-----------------------------+ | | Padding Next Boundary | | +-----------------------------+ <-- *ivt v | Image Vector Table | ------- +-----------------------------+ <-- *csf | | | Command Sequence File (CSF) | | | +-----------------------------+ | Padding (optional) | +-----------------------------+
------- +-----------------------------+ <-- *load_address ^ | | | | | | | | | | | | | fitImage | Signed | | | Data | | | | | | | +-----------------------------+ | | Padding Next Boundary | | +-----------------------------+ <-- *ivt v | Image Vector Table | ------- +-----------------------------+ <-- *csf | | | Command Sequence File (CSF) | | | +-----------------------------+ | Padding (optional) | +-----------------------------+
------- +-----------------------------+ <-- *load_address
^ | |
| | |
| | |
| | |
| | Hamlet |
Signed | | |
Data | | William Shakespeare |
| | |
| +-----------------------------+
| | Padding Next Boundary |
| +-----------------------------+ <-- *ivt
v | Image Vector Table |
------- +-----------------------------+ <-- *csf
| |
| Command Sequence File (CSF) |
| |
+-----------------------------+
| Padding (optional) |
+-----------------------------+
We know about fit image contains kernel, dtb and what ever you want.
And I have shown the code.
Have you even follow the document. use the genIVT.pl to generate the ivt
and append to the end of your fit image. of course, you need to pad the fit to the first 0x1000 as document says.
genIVT.pl is an example, you need to change it accordingly.
BTW, booti and bootm just integrate the authenticate_image the exaclty the same function of hab_auth_img into it.
I suggest you can read the code I have shown you.
"return (fit_get_size(buf) + 0x1000 - 1) & ~(0x1000 - 1); " that is why document ask you to pad the image.
and append the ivt to the end of this padded image.
3.1 Padding the image ---------------------- The Image must be padded to the size specified in the Image header, this can be achieved by using the od command. - Read Image size: $ od -x -j 0x10 -N 0x4 --endian=little Image 0000020 5000 0145 0000024 The tool objcopy can be used for padding the image. - Pad the Image: $ objcopy -I binary -O binary --pad-to 0x1455000 --gap-fill=0x00 \ Image Image_pad.bin
3.2 Generating Image Vector Table ----------------------------------
The HAB code requires an Image Vector Table (IVT) for determining the image length and the CSF location. Since Image does not include an IVT this has to be manually created and appended to the end of the padded Image, the script genIVT.pl in script_examples directory can be used as reference. - Generate IVT: $ genIVT.pl Note: The load Address may change depending on the device. - Append the ivt.bin at the end of the padded Image: $ cat Image_pad.bin ivt.bin > Image_pad_ivt.bin
#! /usr/bin/perl -w use strict; open(my $out, '>:raw', 'ivt.bin') or die "Unable to open: $!"; print $out pack("V", 0x412000D1); # Signature print $out pack("V", 0x80800000); # Load Address (*load_address) print $out pack("V", 0x0); # Reserved print $out pack("V", 0x0); # DCD pointer print $out pack("V", 0x0); # Boot Data print $out pack("V", 0x80EEA000); # Self Pointer (*ivt) print $out pack("V", 0x80EEA020); # CSF Pointer (*csf) print $out pack("V", 0x0); # Reserved close($out);
bootm.c
#if defined(CONFIG_LEGACY_IMAGE_FORMAT)
case IMAGE_FORMAT_LEGACY:
if (authenticate_image(image_load_addr,
image_get_image_size((image_header_t *)image_load_addr)) != 0) {
printf("Authenticate uImage Fail, Please check\n");
return 1;
}
int authenticate_image(uint32_t ddr_start, uint32_t raw_image_size)
{
uint32_t ivt_offset;
size_t bytes;
ivt_offset = (raw_image_size + ALIGN_SIZE - 1) &
~(ALIGN_SIZE - 1);
bytes = ivt_offset + IVT_SIZE + CSF_PAD_SIZE;
return imx_hab_authenticate_image(ddr_start, bytes, ivt_offset);
}
break;
#endif
@BiyongSUN
Thank you for your extended explanation, but I could successfully sign a uImage using the guide, as I have already said in the initial post. In fact, I have written a shell script to automize the process. You can test it out by changing the paths where it says "CHANGE HERE" and then passing the image and load_address as arguments. You are probably not going to do that, but trust me that it works. I have verified the process manually.
Bottom line is: It does not work with a FIT image.
Your colleague @Yuri also says that signing a FIT image is not possible. I am a bit confused:
if [ "$#" -ne 2 ]; then
echo "Illegal number of arguments. Usage: ./habv4_sign_kernel_image.sh IMAGE LOAD_ADDR"
exit 1
fi
# Determine basic filenames, paths and sizes
USB_KERNEL_TARGET="$1"
LOAD_ADDR=$2
ANDROID_DIR=$PWD
IMAGE_NAME=$( basename "$USB_KERNEL_TARGET" )
IMAGE_DIR=$( dirname "$USB_KERNEL_TARGET" )
IMAGE_SIZE="0x`hexdump -C ${USB_KERNEL_TARGET} | tail -n 1`"
PADDED_SIZE="0x`printf '%x\n' $(( ($IMAGE_SIZE + 0x1000 - 1) & ~(0x1000 - 1) ))`"
SIGNED_IMAGE_SIZE="0x`printf '%x\n' $(( PADDED_SIZE + 0x20 ))`"
set -e
echo ""
echo "#### Signing $IMAGE_NAME... ####"
echo ""
echo "Image name: "${IMAGE_NAME}
echo "Image directory: "${IMAGE_DIR}
echo "Image size = "${IMAGE_SIZE}
# Pad the kernel image to 4kB and save it as $(IMAGE)-padded
echo "Padding kernel image to 4kB..."
objcopy -I binary -O binary --pad-to $PADDED_SIZE --gap-fill=0x00 \
${IMAGE_DIR}"/"$IMAGE_NAME ${IMAGE_DIR}"/"$IMAGE_NAME"-padded"
NEW_SIZE="0x`hexdump -C ${IMAGE_DIR}"/"$IMAGE_NAME"-padded" | tail -n 1`"
echo "New size = "${NEW_SIZE}
# Verify if the size is as expected
if [[ $PADDED_SIZE -ne $NEW_SIZE ]]; then
echo -e "\033[31mPadded size and calculated size do not match. Check the image signing script! Exiting..."
echo -e "\033[0m"
exit 1
fi
# Copy the Perl script for generating the IVT and replace its content as needed
cp $ANDROID_DIR"/path/to/genIVT.pl" \ # <--- CHANGE HERE
$IMAGE_DIR
IVT_ADDR="0x`printf "%x\n" $(( $LOAD_ADDR + $PADDED_SIZE ))`"
CSF_ADDR="0x`printf "%x\n" $(( $IVT_ADDR + 0x20 ))`"
echo "Load address = "$LOAD_ADDR
echo "IVT address = "$IVT_ADDR
echo "CSF address = "$CSF_ADDR
sed -i s/0x80800000/$LOAD_ADDR/ $IMAGE_DIR"/genIVT.pl"
sed -i s/0x80EEA000/$IVT_ADDR/ $IMAGE_DIR"/genIVT.pl"
sed -i s/0x80EEA020/$CSF_ADDR/ $IMAGE_DIR"/genIVT.pl"
cd $IMAGE_DIR
chmod +x ./genIVT.pl
./genIVT.pl
cd $ANDROID_DIR
cat $IMAGE_DIR"/"$IMAGE_NAME"-padded" $IMAGE_DIR"/ivt.bin" > $IMAGE_DIR"/"$IMAGE_NAME"-padded-ivt"
# Copy the CSF text file and replace its content as needed
cp $ANDROID_DIR"/path/to/csf_additional_images.txt" $IMAGE_DIR # <--- CHANGE HERE
sed -i -e 's/..\/crts/path\/to\/crts/gm' \ # <--- CHANGE HERE
$IMAGE_DIR"/csf_additional_images.txt"
sed -i -e "s/0x80800000 0x00000000 0x006EA000 \"zImage\".*/$LOAD_ADDR 0x00000000 $SIGNED_IMAGE_SIZE \"$IMAGE_NAME-padded-ivt\"/" \
$IMAGE_DIR"/csf_additional_images.txt"
head -n -2 $IMAGE_DIR"/csf_additional_images.txt" > $IMAGE_DIR"/tmp.txt"
mv $IMAGE_DIR"/tmp.txt" $IMAGE_DIR"/csf_additional_images.txt"
#cat $IMAGE_DIR"/csf_additional_images.txt"
echo ""
# Generate the CSF binary and append it as well to receive the signed image
#echo "Changing working directory to "$IMAGE_DIR
cd $IMAGE_DIR
$ANDROID_DIR"/path/to/cst" \ # <--- CHANGE HERE
--i "csf_additional_images.txt" --o "csf_"$IMAGE_NAME
echo "Appending CSF file to image..."
cat $IMAGE_NAME"-padded-ivt" "csf_"$IMAGE_NAME > $IMAGE_NAME"-signed"
# Calculating and determining sizes
PADDED_IVT_SIZE="0x`hexdump -C $IMAGE_NAME"-padded-ivt" | tail -n 1`"
CSF_SIZE="0x`hexdump -C "csf_"$IMAGE_NAME | tail -n 1`"
TOTAL_CALCULATED_SIZE="0x`printf '%x\n' $(( $CSF_SIZE + $PADDED_IVT_SIZE ))`"
ACTUAL_SIGNED_IMAGE_SIZE="0x`hexdump -C $IMAGE_NAME"-signed" | tail -n 1`"
# Verify if the size is as expected
if [[ $TOTAL_CALCULATED_SIZE -ne $ACTUAL_SIGNED_IMAGE_SIZE ]]; then
echo -e "\033[31mSize of the signed image and calculated size do not match. Check the image signing script! Exiting..."
echo -e "\033[0m"
exit 1
fi
## Cleanup
echo "Cleaning up..."
rm genIVT.pl
rm ivt.bin
rm csf_additional_images.txt
rm "csf_"$IMAGE_NAME
rm $IMAGE_NAME"-padded"
rm $IMAGE_NAME"-padded-ivt"
#mv $IMAGE_NAME $IMAGE_NAME"-unsigned"
mv $IMAGE_NAME"-signed" $IMAGE_NAME
echo ""
echo -e "\033[32m#### $IMAGE_NAME signed successfully! ####"
echo -e "\033[0m"
#echo "Changing working directory to "$ANDROID_DIR
cd $ANDROID_DIR
1. I am geting and "Invalid IVT header" error --- suggest you can one by one check the address and all the files. not by your script. or you can use hex edit to check if the ivt is really the code want it.
2. lots of cases using fit image with HAB sign.
3. I don't think uImage is different from fit image.
4. you can test your signed image with authenticate_image as debug method. give third parameter ivt offset.
So you are assuring me that it works with a FIT image, which is great news! Maybe we can find me error together then!
This is the output from my shell script, which prints all the required data
#### Started the HABv4 kernel image signing routine ####
Image name: fitImage
Image directory: .
Image size = 0x0285d200
Padded size = 0x0285e000
Padding kernel image to 4kB...
New size = 0x0285e000
Load address = 0x44000000
IVT address = 0x4685e000
CSF address = 0x4685e020
CSF Processed successfully and signed data available in csf_fitImage
Appending CSF file to image...
Signed image size = 0x0285ef60
#### Kernel image signed successfully! ####
When I try to manually authenticate the image, I get "No HAB Events found!". Does this mean the authentication was successful?
u-boot=> hab_auth_img 0x44000000 0x0285ef60 0x0285e000
Authenticate image from DDR location 0x44000000...
Secure boot enabled
HAB Configuration: 0xcc, HAB State: 0x99
No HAB Events Found!
When I try to boot the FIT image, I get an error though. It is also weird that U-Boot doesn't detect it as a FIT image anymore.
u-boot=> bootm 0x44000000
Authenticate image from DDR location 0x40480000...
bad magic magic=0xfd length=0xff77 version=0xff
bad length magic=0xfd length=0xff77 version=0xff
bad version magic=0xfd length=0xff77 version=0xff
Error: Invalid IVT structure
Allowed IVT structure:
IVT HDR = 0x4X2000D1
IVT ENTRY = 0xXXXXXXXX
IVT RSV1 = 0x0
IVT DCD = 0x0
IVT BOOT_DATA = 0xXXXXXXXX
IVT SELF = 0xXXXXXXXX
IVT CSF = 0xXXXXXXXX
IVT RSV2 = 0x0
Authenticate uImage Fail, Please check
I did the test. It is caused by the wrong ivt_offset . When I used the function(fit_get_size((void *)load_addr)) to get the fitimage size, I can get the correct ivt_offset. No HAB Event were reported. What confused me was that the final calculated fitimage_signed(bytes = ivt_offset + IVT_SIZE + CSF_PAD_SIZE) was not the same as the actual size, and he did not report an HAB Event.
HI, I have the same problem as you. I did not find HAB Event when I used cmd command(imx_auth_img ).
load address: 0x40480000
fitimage size: 0x30a0094
padded fitimage: 0x30a1000
fitimage_padde_ivt: 0x30a1020
fit_signed: 0x30a1f60
imx_auth_img 0x40480000 0x30a1f60 0x30a1000 No HAB Events Found!
I used the following script
So I find that the parameter of imx_hab_authenticate_image(ddr_start,bytes,ivt_offset) function is calculated incorrectly.
arch\arm\mach-imx\hab.c imx_hab_authenticate_image(ddr_start,bytes,ivt_offset)
ivt_offset = (raw_image_size + ALIGN_SIZE - 1) &~(ALIGN_SIZE - 1);
bytes = ivt_offset + IVT_SIZE + CSF_PAD_SIZE;
return imx_hab_authenticate_image(ddr_start, bytes, ivt_offset);
bytes - ivt_offset = IVT_SIZE + CSF_PAD_SIZE = 0x20 +0x2000 = 0x2020;
fit_signed - padded fitimage = 0x30a1f60 - 0x30a1000 = 0xf60;
Therefore, the definition of the two macros is different from the actual offset size, which will cause the parameter calculation error.
The ivt_offset size is also different from the actual size(fit_signed: 0x30a1f60), which may be due to the error of the previous function(image_get_image_size((image_header_t *)image_load_addr))) that obtained fitimage.
So I would like to ask you, did you finally solve this problem by modifying the calculation process of this function(int authenticate_image(uint32_t ddr_start, uint32_t raw_image_size))
It seems u-boot hasn't enable the fit for the bootm command.
it recognizes the fit image as legacy uImage format. maybe you haven't enable CONFIG_SPL_FIT_SIGNATURE.
That causes address calculate wrong of the offset for the ivt.
That is why when you use "hab_auth_img 0x44000000 0x0285ef60 0x0285e000" with "Authenticate image from DDR location 0x44000000..." . it pass.
but the bootm log shows "Authenticate image from DDR location 0x40480000...".
That is address difference.
@BiyongSUN I could solve it now using this patch
I wonder why this was not enabled by default yet. Is there a good reason?
@BiyongSUN It worked, but now it doesn't work anymore. Unfortunately I did not commit the state.
Here is my U-Boot configuration. Could anything else be missing? I can boot the FIT without CONFIG_SECURE_BOOT, but not when it is activated.
CONFIG_ARM=y
CONFIG_ARCH_IMX8M=y
CONFIG_SYS_TEXT_BASE=0x40200000
CONFIG_SYS_MALLOC_F_LEN=0x2000
CONFIG_TARGET_GPV_IMX8MM=y
CONFIG_SPL_MMC_SUPPORT=y
CONFIG_FLASH_MCUFIRMWARE_SUPPORT=y
CONFIG_DEFAULT_DEVICE_TREE="gpv-imx8mm"
CONFIG_FIT=y
CONFIG_SPL_LOAD_FIT=y
CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=arch/arm/mach-imx/spl_sd.cfg,SPL_TEXT_BASE=0x7E1000,ANDROID_SUPPORT"
CONFIG_ARCH_MISC_INIT=y
CONFIG_SPL=y
CONFIG_SPL_BOARD_INIT=y
CONFIG_SPL_USB_HOST_SUPPORT=y
CONFIG_SPL_USB_GADGET_SUPPORT=y
CONFIG_SPL_USB_SDP_SUPPORT=y
CONFIG_HUSH_PARSER=y
CONFIG_NOT_UUU_BUILD=y
CONFIG_CMD_MEMTEST=y
CONFIG_CMD_GPIO=y
CONFIG_CMD_I2C=y
CONFIG_CMD_SF=y
CONFIG_CMD_CACHE=y
CONFIG_CMD_REGULATOR=y
CONFIG_CMD_EXT2=y
CONFIG_CMD_EXT4=y
CONFIG_CMD_EXT4_WRITE=y
CONFIG_CMD_FAT=y
CONFIG_EFI_PARTITION=y
CONFIG_OF_CONTROL=y
CONFIG_ENV_IS_IN_MMC=y
CONFIG_DM_GPIO=y
CONFIG_DM_I2C=y
CONFIG_SYS_I2C_MXC=y
CONFIG_DM_MMC=y
CONFIG_DM_SPI_FLASH=y
CONFIG_SPI_FLASH=y
CONFIG_SPI_FLASH_STMICRO=y
CONFIG_DM_ETH=y
CONFIG_PINCTRL=y
CONFIG_PINCTRL_IMX8M=y
CONFIG_DM_REGULATOR=y
CONFIG_DM_REGULATOR_FIXED=y
CONFIG_DM_REGULATOR_GPIO=y
CONFIG_DM_RESET=y
CONFIG_DM_SPI=y
CONFIG_FSL_FSPI=y
CONFIG_DM_THERMAL=y
CONFIG_NXP_TMU=y
CONFIG_USB=y
CONFIG_DM_USB=y
CONFIG_USB_EHCI_HCD=y
CONFIG_USB_GADGET=y
CONFIG_USB_GADGET_MANUFACTURER="FSL"
CONFIG_USB_GADGET_VENDOR_NUM=0x0525
CONFIG_USB_GADGET_PRODUCT_NUM=0xa4a5
CONFIG_SDP_LOADADDR=0x40400000
CONFIG_USB_GADGET_DOWNLOAD=y
CONFIG_VIDEO=y
CONFIG_VIDEO_TI_SN65DSI83=y
CONFIG_APPEND_BOOTARGS=y
CONFIG_LZ4=y
CONFIG_SPL_FIT_SIGNATURE=y
CONFIG_SECURE_BOOT=y
You can check with the BSP release in
uboot-imx - i.MX U-Boot (codeaurora.org)
please use tag to checkout.
# CONFIG_SPL_FIT_PRINT is not set
# CONFIG_SPL_FIT_FULL_CHECK is not set
CONFIG_SPL_LOAD_FIT=y
CONFIG_SPL_LOAD_FIT_ADDRESS=0x0
# CONFIG_SPL_LOAD_FIT_APPLY_OVERLAY is not set
# CONFIG_SPL_LOAD_FIT_FULL is not set
It doesn't matter, you can add your own code to do the same authentication.
cst just has "agreement" with u-boot, where to get the ivt, right?
This is weird. U-Boot also boots unsigned FIT images. Secure Boot is definitely enabled. This is really a problem now.
When I look at https://source.codeaurora.org/external/imx/uboot-imx/tree/configs/imx8mm_evk_android_defconfig?h=p9...., I only see the following
CONFIG_FIT=y CONFIG_SPL_LOAD_FIT=y
and I already have them included.
I also tried your suggestion with 0x0 and 0x44000000, where I load my FIT image to, but both don't work.
# CONFIG_SPL_FIT_PRINT is not set
# CONFIG_SPL_FIT_FULL_CHECK is not set
CONFIG_SPL_LOAD_FIT=y
CONFIG_SPL_LOAD_FIT_ADDRESS=0x0
# CONFIG_SPL_LOAD_FIT_APPLY_OVERLAY is not set
# CONFIG_SPL_LOAD_FIT_FULL is not set
It still recognizes the FIT as a uImage
Authenticate image from DDR location 0x40480000...
bad magic magic=0xff length=0xffff version=0xff
bad length magic=0xff length=0xffff version=0xff
bad version magic=0xff length=0xffff version=0xff
Error: Invalid IVT structure
Allowed IVT structure:
IVT HDR = 0x4X2000D1
IVT ENTRY = 0xXXXXXXXX
IVT RSV1 = 0x0
IVT DCD = 0x0
IVT BOOT_DATA = 0xXXXXXXXX
IVT SELF = 0xXXXXXXXX
IVT CSF = 0xXXXXXXXX
IVT RSV2 = 0x0
Authenticate uImage Fail, Please check
Error loading the OS
EDIT: Well, I just found that when I manually set the loadaddr to 0x44000000, it works. So I am just going with that solution now.
At last!!!
Thank you!