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 70E81C07E95 for ; Tue, 13 Jul 2021 14:30:00 +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 77BA86127C for ; Tue, 13 Jul 2021 14:29:59 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 77BA86127C 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 3579282D13; Tue, 13 Jul 2021 16:29:57 +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="R9/CCef/"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 3722182D6F; Tue, 13 Jul 2021 16:29:55 +0200 (CEST) Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [IPv6:2a00:1450:4864:20::432]) (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 73BA582970 for ; Tue, 13 Jul 2021 16:29:51 +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-wr1-x432.google.com with SMTP id d12so30130431wre.13 for ; Tue, 13 Jul 2021 07:29:51 -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=fCFHlvrhdFHBi4DIvkGft+LhUpkaidGy/0VftVAIwFw=; b=R9/CCef/lY+lsWKdDaIKK+13RF/UbCY+M9P5UZs1ziopW+PZE9TiTgCMC0j9GuxKX/ IQudc94wKc8qyJ3rT4sHLzrKht27UyhB3gXeyVy6v5CiTlPOhEhsqDdoWfMvnfcU9F9i z6njbUKeZnBL8ESvFlYAO9Spjk/IQSYPEoiV+EtuPSDJNwDRs9i3JkejLdn+E9v3NMO2 0h2IOhJ+EE7G3qlyuNAPCodVffuGoBFKxpYTBdhZySTvzniSItlHwxDvUemjgsBVdCa7 syzLHjLr3VwPlVLl8UuULDo1cE8zW7j8Pk9V3w3+LNr2aQmciN5Yz5vVPvT7+Vn2czH9 UnbA== 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=fCFHlvrhdFHBi4DIvkGft+LhUpkaidGy/0VftVAIwFw=; b=WfDXQ/OxBqiPNqTBBQQVs993TmHgr3eiIJFsVmeRcQQ/chLM6gMzWyDTXlmOpoo2kh C+byWD5sMKEcwlcApr+KnqF0X0ni2zQuxafmroQtwr8tis+zix5dzkDjYPUM6xfBu+VA TTlltd/UtR3EJ9TT3uwHcBOp8LluKbeI3iaeYh5tk5nCRbWLDcBE+g2Gj40Mv0SBbdFP I6nmmBdqWq6czEgnnEDlU9v2AoaLbT+sJ6L0buOPrFOLI4y+HU3zPI7tzX9KkqeddMST UPkTXJXP+G6ynoZGMrqff5WO1vTAvkYnJDfjcq8gqE7iMp+HW+VaTtT47DaC4u7h0b8/ Zp7g== X-Gm-Message-State: AOAM531SP4FZYu4bA9TcRzEXY8bxEvo1zg0LYl77NylIvzOsEznB1rhh vVuwiragormcRcNZMrASJRm4IQ== X-Google-Smtp-Source: ABdhPJwmbOwKaaw3d24dI9Tflbpey2mtencwbN8vBGdnsXoagioxvTzh7JziMq7+fyO35dVQMMT95A== X-Received: by 2002:adf:e445:: with SMTP id t5mr6198800wrm.80.1626186591009; Tue, 13 Jul 2021 07:29:51 -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 b12sm14374101wro.1.2021.07.13.07.29.50 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Tue, 13 Jul 2021 07:29:50 -0700 (PDT) From: "Jorge Ramirez-Ortiz, Foundries" X-Google-Original-From: "Jorge Ramirez-Ortiz, Foundries" Date: Tue, 13 Jul 2021 16:29:49 +0200 To: "Jorge Ramirez-Ortiz, Foundries" Cc: Michal Simek , u-boot@lists.denx.de, ricardo@foundries.io Subject: Re: zynqmpbif - sample Message-ID: <20210713142949.GA24849@trex> References: <20210712174043.GA18753@trex> <20210713073229.GA9771@trex> <20210713092528.GA25779@trex> <68f42006-bdbe-bfef-5499-3a51e45c4030@xilinx.com> <20210713113332.GA756@trex> <20210713140000.GA21051@trex> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210713140000.GA21051@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, 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? um, I dont think bootgen can boot spl.bin...seems we need an elf > > > > > > > > > Thanks, > > > Michal > > >