From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.3 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id F2CC4C07E95 for ; Tue, 13 Jul 2021 14:00:14 +0000 (UTC) Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 13836608FE for ; Tue, 13 Jul 2021 14:00:13 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 13836608FE Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=foundries.io Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 95A1782B20; Tue, 13 Jul 2021 16:00:11 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=foundries.io Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (2048-bit key; unprotected) header.d=foundries.io header.i=@foundries.io header.b="FWqe5Ywm"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 5729C82B20; Tue, 13 Jul 2021 16:00:10 +0200 (CEST) Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [IPv6:2a00:1450:4864:20::332]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 6F0DC82D13 for ; Tue, 13 Jul 2021 16:00:02 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=foundries.io Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=jorge@foundries.io Received: by mail-wm1-x332.google.com with SMTP id b14-20020a1c1b0e0000b02901fc3a62af78so1708685wmb.3 for ; Tue, 13 Jul 2021 07:00:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=foundries.io; s=google; h=from:date:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=137pQwmrI9uSz5EUXSrjEVO8AR1DIoIEKAuL4pXThC8=; b=FWqe5YwminJwTZ3WP38HBe8366fvnxd0d1PCNBluc2oXTlJ0KL0qbi4CWJLLjQibUf 2ibZuQasMhliDS8+rcjxdC4z6HEJxsp7phhWrPgti/3TX42RkDtaj7upI4QDXWYGXYcR n9RtSNKoPfFxsH2MQrK464gJ4YsN8uVo6mn7KF6v5n7KIvV+SIt7tRPAt0BcZMussxwn YC982sN/A56Ce6oKtwtMRAIFwiv8Ke5UwM7xQf3oI8t480PovkeBQVppikB9mDJyi52E 5LnxoXP/JdfLe4MaMGaqosTnsm1+6SRJis9gAEAHFNZRHjWvDoLoithgzVcW8WV9jiBZ nsKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:date:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=137pQwmrI9uSz5EUXSrjEVO8AR1DIoIEKAuL4pXThC8=; b=OFXa1g5S/WsaCsUYnlkgY2aRrUalH0xWC6pl2vRmdpkSFbOFhNhPo73tEPEXcXfXkg VP6GPDWjm2yF6o6eHWZsdO5oyT7fYxXcy+PT0Wlwz2RKMPPROIkXXXsm7LourR9WkAfV UW4xVU/IjLsYmuL5LAme+bJD5OZnqyCN2LbkIpp2dFJ+jmg4QFApYj3h2jOQbusyp4xR kW3oSL8Ry+i2fo4lZ5f6eBOp7+dD52oVcPwZxkfcRqoQXcrphQH1hm5srkPOuJcVMYx3 CE9FiX6OgNncy+OX4Owc5uroXPaVA7VRNcckkIl1YHPpdYVYLv4JIyjCa4nQ5rMlI1wH s/IQ== X-Gm-Message-State: AOAM533m0oUNU2ymEXRVX0K9IGlOOd8ryNFSkeSTTZ3RcY00wmJ/3Ina cjSJImQQl/qTgDq6zWBESTndzw== X-Google-Smtp-Source: ABdhPJy2cJo7rIpoCflcL8QDMccy3T/2cB1HRzG8GLGQwJrptL4jizuUYU3lLXXi9kBSnkAy3noluQ== X-Received: by 2002:a1c:9851:: with SMTP id a78mr162741wme.33.1626184801902; Tue, 13 Jul 2021 07:00:01 -0700 (PDT) Received: from trex (138.red-79-146-80.dynamicip.rima-tde.net. [79.146.80.138]) by smtp.gmail.com with ESMTPSA id e3sm18572057wra.15.2021.07.13.07.00.00 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Tue, 13 Jul 2021 07:00:01 -0700 (PDT) From: "Jorge Ramirez-Ortiz, Foundries" X-Google-Original-From: "Jorge Ramirez-Ortiz, Foundries" Date: Tue, 13 Jul 2021 16:00:00 +0200 To: "Jorge Ramirez-Ortiz, Foundries" Cc: Michal Simek , u-boot@lists.denx.de, ricardo@foundries.io Subject: Re: zynqmpbif - sample Message-ID: <20210713140000.GA21051@trex> References: <20210712174043.GA18753@trex> <20210713073229.GA9771@trex> <20210713092528.GA25779@trex> <68f42006-bdbe-bfef-5499-3a51e45c4030@xilinx.com> <20210713113332.GA756@trex> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210713113332.GA756@trex> User-Agent: Mutt/1.9.4 (2018-02-28) X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.34 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.2 at phobos.denx.de X-Virus-Status: Clean On 13/07/21, Jorge Ramirez-Ortiz, Foundries wrote: > On 13/07/21, Michal Simek wrote: > > > > > > On 7/13/21 11:25 AM, Jorge Ramirez-Ortiz, Foundries wrote: > > > On 13/07/21, Jorge Ramirez-Ortiz, Foundries wrote: > > >> On 13/07/21, Michal Simek wrote: > > >>> Hi, > > >>> > > >>> On 7/12/21 7:40 PM, Jorge Ramirez-Ortiz, Foundries wrote: > > >>>> hi Michal, > > >>>> > > >>>> Would you have some sample/reference code to generate a SPL boot image > > >>>> using zynqmpbif instead of zynqmpimage? I cant find any documentation > > >>>> and I see no option to enable it (I was expecting to find some config > > >>>> in Makefile.spl but I see none). > > >>>> > > >>>> What is the expected way of building these images? > > >>> > > >>> Alex implemented it for Xilinx bif format after origin zynqmpimage > > >>> format. But usage is just like this. > > >>> > > >>> [u-boot](debian-sent)$ ./tools/mkimage -T zynqmpbif -d /tmp/bif > > >>> /tmp/boot.bin > > >>> Image Type : Xilinx ZynqMP Boot Image support > > >>> Image Offset : 0x000009c0 > > >>> Image Size : 147216 bytes (147216 bytes packed) > > >>> PMUFW Size : 129792 bytes (129792 bytes packed) > > >>> Image Load : 0xfffc0000 > > >>> Checksum : 0xfd15d661 > > >>> [u-boot](debian-sent)$ cat /tmp/bif > > >>> image : { > > >>> [pmufw_image, load=0xffdc0000] /mnt/disk/u-boot-bins/zynqmp/pmu.elf > > >>> [destination_cpu=a53-0, load=0xfffc0000, bootloader] spl/u-boot-spl.bin > > >>> } > > >> > > >> awesome, exactly what I needed to start with. > > > > > > So I can boot using the steps you mentioned above. > > > > > > But shouldnt the same bif work with bootgen? > > > > > > ****** Xilinx Bootgen v2019.2 > > > **** Build date : Oct 23 2019-22:59:42 > > > ** Copyright 1986-2019 Xilinx, Inc. All Rights Reserved. > > > > > > [TRACE] : Command Line parsing started > > > [TRACE] : Command: -arch zynqmp -image ./bif -w -o bootbif.bin -log trace > > > [INFO] : Command line parsing completed successfully > > > [TRACE] : BIF File: ./bif > > > [TRACE] : BIF file parsing started > > > [TRACE] : Setting PMU FW Image file as pmu.elf > > > [INFO] : BIF file parsing completed successfully > > > [INFO] : Parsing Partition Data to Image > > > [INFO] : Building image - image > > > [INFO] : Building the Partition Header Table > > > [INFO] : After build > > > -- Dump of Binary Image ---- > > > 00000000 Len: 000008b8 Res: 00000000 "BootHeader" > > > 00000000 Len: 00000040 Res: 00000000 "ImageHeaderTable" > > > 00000000 Len: 00000024 Res: 00000800 "ImageHeader u-boot-spl.bin" > > > 00000000 Len: 00000040 Res: 00000000 "PartitionHeader u-boot-spl.bin.0" > > > 00000000 Len: 00000040 Res: 000016c0 "PartitionHeader Null" > > > 00000000 Len: 00020574 Res: 00000000 "u-boot-spl.bin.0" > > > -- End of Dump > > > [INFO] : After align > > > -- Dump of Binary Image ---- > > > 00000000 Len: 000008b8 Res: 00000000 "BootHeader" > > > 000008c0 Len: 00000040 Res: 00000000 "ImageHeaderTable" > > > 00000900 Len: 00000024 Res: 00000800 "ImageHeader u-boot-spl.bin" > > > 00001100 Len: 00000040 Res: 00000000 "PartitionHeader u-boot-spl.bin.0" > > > 00001140 Len: 00000040 Res: 000016c0 "PartitionHeader Null" > > > 00002800 Len: 00020574 Res: 00000000 "u-boot-spl.bin.0" > > > -- End of Dump > > > [INFO] : Partition Information: > > > [INFO] : Image: u-boot-spl.bin > > > [INFO] : Partition 0: u-boot-spl.bin.0, Size: 132467 > > > [INFO] : After Link > > > -- Dump of Binary Image ---- > > > 00000000 Len: 000008b8 Res: 00000000 "BootHeader" > > > 000008c0 Len: 00000040 Res: 00000000 "ImageHeaderTable" > > > 00000900 Len: 00000024 Res: 00000800 "ImageHeader u-boot-spl.bin" > > > 00001100 Len: 00000040 Res: 00000000 "PartitionHeader u-boot-spl.bin.0" > > > 00001140 Len: 00000040 Res: 000016c0 "PartitionHeader Null" > > > 00002800 Len: 00020574 Res: 00000000 "u-boot-spl.bin.0" > > > -- End of Dump > > > > > > > > > however when I boot and inspect the processor state, xsdb returns "APU > > > L2 cache is held in reset" > > > > > > Since the functionality to support RSA authentication is missing from > > > mkimage (I'll have to add that), I would first like to see it > > > functional with SPL using bootgen. > > > > > > However the same bif doesnt even boot - is this to be expected? > > > > > > also the layouts generated from the bif using mkimage and bootgen are > > > completely different (it seems that naively I expected them to be the > > > same); is there any information on the different layouts used for the > > > bootrom? > > > > > > I tested it and it works fine for me. Take a look at the code what > > exactly is > > > > [u-boot]$ cat /tmp/bif > > image : { > > [pmufw_image] /mnt/disk/u-boot-bins/zynqmp/pmu.bin > > [destination_cpu=a53-0, load=0xfffc0000, bootloader] > > spl/u-boot-spl-align.bin > > } > > > > Didn't try the latest bootgen but format is changing over years but none > > is updating this tool. Feel free to take a look at it. > > weird, I can not boot the bin when using bootgen 2019 nor 2021. > > please can you send me the output of the following command so I can compare? > vivado@trex:~/deploy/bootgen_bif$ bootgen -read boot.bin > > also, are you booting from QSPI? > > thanks a lot! just for reference: $ cat bif the_ROM_image: { [pmufw_image, load=0xffdc0000] pmu.elf [destination_cpu=a53-1, load=0xfffc0000, bootloader] u-boot-spl-align.bin } BOOTGEN ======== $./bootgen -arch zynqmp -image ./bif -w -o bootbif.bin will generate this image: $ ./bootgen -read bootbif.bin ****** Xilinx Bootgen v2021.1 **** Build date : Jun 18 2021-09:23:50 ** Copyright 1986-2021 Xilinx, Inc. All Rights Reserved. -------------------------------------------------------------------------------- BOOT HEADER -------------------------------------------------------------------------------- boot_vectors (0x00) : 0x1400000014000000140000001400000014000000140000001400000014000000 width_detection (0x20) : 0xaa995566 image_id (0x24) : 0x584c4e58 encryption_keystore (0x28) : 0x00000000 header_version (0x2c) : 0x00000000 fsbl_sourceoffset (0x30) : 0x00002800 fsbl_length (0x34) : 0x00000000 fsbl_load_address (0x38) : 0x00000000 fsbl_exec_address (0x3C) : 0x00000000 fsbl_total_length (0x40) : 0x00000000 qspi_config-word (0x44) : 0x00000800 checksum (0x48) : 0xfd1a2c41 iht_offset (0x98) : 0x000008c0 pht_offset (0x9c) : 0x00001100 -------------------------------------------------------------------------------- IMAGE HEADER TABLE -------------------------------------------------------------------------------- version (0x00) : 0x01020000 total_images (0x04) : 0x00000001 pht_offset (0x08) : 0x00001100 ih_offset (0x0c) : 0x00000900 hdr_ac_offset (0x10) : 0x00000000 -------------------------------------------------------------------------------- IMAGE HEADER (u-boot-spl-align.bin) -------------------------------------------------------------------------------- next_ih(W) (0x00) : 0x00000000 next_pht(W) (0x04) : 0x00000440 total_partitions (0x08) : 0x00000000 total_partitions (0x0c) : 0x00000001 name (0x10) : u-boot-spl-align.bin -------------------------------------------------------------------------------- PARTITION HEADER TABLE (u-boot-spl-align.bin.0) -------------------------------------------------------------------------------- encrypted_length (0x00) : 0x0000815d unencrypted_length (0x04) : 0x0000815d total_length (0x08) : 0x0000815d load_addr (0x0c) : 0x00000000 exec_addr (0x10) : 0x00000000 partition_offset (0x14) : 0x00000000 attributes (0x18) : 0xfffc0000 section_count (0x1C) : 0x00000000 checksum_offset (0x20) : 0x00000a00 iht_offset (0x24) : 0x00000216 ac_offset (0x28) : 0x00000001 checksum (0x3c) : 0x00026d91 attribute list - trustzone [non-secure] el [el-0] exec_state [aarch-64] dest_device [none] encryption [no] core [none] -------------------------------------------------------------------------------- AUTHENTICATION CERTIFICATE (u-boot-spl-align.bin.0) -------------------------------------------------------------------------------- -------------------------------------------------------------------------------- which will NOT boot (the fsbl information in the bootheader seems a source of concern but I dont know...hence why I was asking before about the one it worked for you) MKIMAGE ======== Using mkimage - as you indicated- we can generate an image that will boot from QSPI ./mkimage -T zynqmpbif -d bif bootbif.bin Image Type : Xilinx ZynqMP Boot Image support Image Offset : 0x000009c0 Image Size : 132468 bytes (132468 bytes packed) PMUFW Size : 129792 bytes (129792 bytes packed) Image Load : 0xfffc0000 Checksum : 0xfd164999 But the bin image is NOT readable by bootgen jramirez@trex bootgen_bif (master *%)$ ./bootgen -read bootbif.bin ****** Xilinx Bootgen v2021.1 **** Build date : Jun 18 2021-09:23:50 ** Copyright 1986-2021 Xilinx, Inc. All Rights Reserved. [ERROR] : Error reading Image header So both utilities do generate different bootheaders and layouts. The layout that doesnt boot - the one generated with bootgen - is the one documented in https://www.xilinx.com/support/documentation/sw_manuals/xilinx2018_2/ug1283-bootgen-user-guide.pdf And the one that does work - using a boot header not readable by bootgen!- is not documented anywhere AFAIK. I am confused at this point. Is there any public information about the bootrom? does the above information make sense to you? > > > > > Thanks, > > Michal > >