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=-17.2 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_SANE_1 autolearn=ham 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 AB2E2C12002 for ; Wed, 14 Jul 2021 22:10:46 +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 179EC6101B for ; Wed, 14 Jul 2021 22:10:46 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 179EC6101B 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 8FBBC82BFA; Thu, 15 Jul 2021 00:10:44 +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="XYup94Mh"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 3770C82F1D; Thu, 15 Jul 2021 00:10:43 +0200 (CEST) Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [IPv6:2a00:1450:4864:20::32d]) (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 BCAEE82000 for ; Thu, 15 Jul 2021 00:10:38 +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-x32d.google.com with SMTP id y21-20020a7bc1950000b02902161fccabf1so4811431wmi.2 for ; Wed, 14 Jul 2021 15:10:38 -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=y2fKasFqqLeAFnMK+7otChZy7UfP5AjYTORyWm+7gQQ=; b=XYup94MhzAv8K5thOUJWVYZe7jH8kmB0AW/D/5h9DblAtJkIwwvUxzbwyInlwmPgLp M3w2zpDNF+nqOeJUd3Da0gkamljf/N6MGZCXwBsX6jpoKg87993cQpfywhvUl0zovsKh zcKB/7Gvk5DvESzLZCVwWWqs3X6d++exdFbJccbzZCSZ3Nlvtncayl4klhrz/ffU0u6U S/DxALtFZFZAqCDK9scneY6TygCymDEijeURUUrTMVnz+8hfRX2VGUS6z5L4tfCnzIMu +7Er4JMyO//sb8TBmzhcG0HSpVQNer17m75vObbFxqPuzcVVN9lYWydf/smeG5uU7cFA KwSQ== 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=y2fKasFqqLeAFnMK+7otChZy7UfP5AjYTORyWm+7gQQ=; b=BZAyywGUb9YYaePF0pWAzl9vRRUKh5qAj42ceKniej2ZKYDbOVG/twYxgHPf8Ob0W0 QamHq7DRXilK2SeiQGTrs8QknOXJI4Goq39nGJUZnIVj3xRKtfVdOFqDnwuC2Di9T+R4 PSkGnUz6KveRv5cpQMSpjl3Ty8QGW3CB2AS1LhfioH+O+L566wEYeAfcn+IqDpX1nWeV RUy+Y6TgVAK8u8AHyTGr+ZjikLd1lh6AdFh03BHYEgQchGn8jznn5AdnZehn6wjMbjnx 5qOnYj+WtwxSBQVXFfpAbcm1L3Hy66F9qsPJqtY4n9Kn/70g8yLgdmogfenKJG0wijnG Rgpg== X-Gm-Message-State: AOAM533GmmdOrBRiFOsQxl05Dqc0qWEijWBpCEGn84tOIvY0bRJ3rD2H 91JBBcrIImgrEkE+Hjpsr7ZTD9J27aycvw== X-Google-Smtp-Source: ABdhPJy5paGU9l4qg6QEIVxpT/vBahsChM8ItlcBza/DEOHKmJlw6S19LdO4F+L2PRtSTjtEn6Qs5A== X-Received: by 2002:a7b:c92b:: with SMTP id h11mr320615wml.182.1626300638156; Wed, 14 Jul 2021 15:10:38 -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 o6sm3856619wry.91.2021.07.14.15.10.37 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Wed, 14 Jul 2021 15:10:37 -0700 (PDT) From: "Jorge Ramirez-Ortiz, Foundries" X-Google-Original-From: "Jorge Ramirez-Ortiz, Foundries" Date: Thu, 15 Jul 2021 00:10:36 +0200 To: Michal Simek Cc: "Jorge Ramirez-Ortiz, Foundries" , u-boot@lists.denx.de, ricardo@foundries.io Subject: Re: zynqmpbif - sample Message-ID: <20210714221036.GA15194@trex> References: <20210712174043.GA18753@trex> <20210713073229.GA9771@trex> <20210713092528.GA25779@trex> <68f42006-bdbe-bfef-5499-3a51e45c4030@xilinx.com> <20210713113332.GA756@trex> <20210713140000.GA21051@trex> <20210713142949.GA24849@trex> <20210714073748.GA29594@trex> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 14/07/21, Michal Simek wrote: > Hi, > > On 7/14/21 9:37 AM, Jorge Ramirez-Ortiz, Foundries wrote: > > On 13/07/21, Jorge Ramirez-Ortiz, Foundries wrote: > >> 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 > > > > so yes, I doubt it can work for you either. I suppose you misread the > > question. > > > > BTW where is the image layout zynqmpimage or zynqmpbif documented? > > I am not refereing to the boot header fields - those are clear - but > > mostly interested about the 0x9c0 address. > > > > We are placing the pmufw at that location (0x9c0) and right after > > spl.bin...why does this boot? AFAICS it does not follow the documented > > layout so it shouldnt... > > > > https://www.xilinx.com/html_docs/xilinx2020_2/vitis_doc/bootimagelayout.html#uyu1526489661314 > > > > I'd like to be able to extend zynqmpbif with support for > > authentication but ATM I am lacking some basic information. > > > > Anything you can share that would be great. > > > > I have never tried to boot bootimage generaged from that bif with > bootgen. Only boot.bin generated by mkimage with zynqmpbif based on > provided bif file. > > This code was developed long time ago and I have never used zynqmpbif > but I use zynqmpimage all the time because it is wired with make for > spl/boot.bin generation. > > In past also the code was developed by reverse engineering of images to > find out the bare minimum required for boot. And TBH this is the first > time I see detailed description of boot headers. It wasn't public > information in past. It would be interesting to use secondary boot > device from Image Header table which we are doing differently now in SPL. > > Definitely feel free to extend it. I am happy to test it and review. I added bin support to bootgen ; now we can use the same bif on mkimage and bootgen. so using the_ROM_image: { [pmufw_image, load=0xffdc0000] pmu.bin [bootloader, destination_cpu=a53-0, load=0xfffc0000] u-boot-spl.bin } And https://github.com/Xilinx/bootgen.git (HEAD -> master, tag: xilinx_v2021.1, origin/xlnx-rel-v2021.1, origin/master, origin/HEAD) commit 34c4313a09dd75cf6ff5b188136e1a077c5b0aa2 Author: RamyaSree Date: 7 weeks ago 2021.1 Updates with these changes: diff --git a/imageheadertable-zynqmp.cpp b/imageheadertable-zynqmp.cpp index f06ca71..6832fc9 100755 --- a/imageheadertable-zynqmp.cpp +++ b/imageheadertable-zynqmp.cpp @@ -384,6 +384,32 @@ void ZynqMpImageHeader::ImportBin(BootImage& bi) hdr->execState = A53ExecState::AARCH32; } + if (Bootloader) { + /* hacking: add PMU FW before SPL */ + + std::string pmu_fw = bi.bifOptions->GetPmuFwImageFile(); + ByteFile pmu_fw_data(pmu_fw); + Binary::Length_t pmu_size = pmu_fw_data.len; + + uint8_t *partition_data = (uint8_t *)malloc(pmu_size); + memcpy(partition_data, pmu_fw_data.bytes, pmu_size); + + uint8_t pmu_padding = (4 - (pmu_size & 3)) & 3; + pmuFwSize = totalPmuFwSize = pmu_size + pmu_padding; + + partition_data = (uint8_t *)realloc(partition_data, pmuFwSize + data.len); + + memset(partition_data + pmu_size, 0, pmu_padding); + memcpy(partition_data + pmuFwSize, data.bytes, data.len); + + data.bytes = partition_data; + fsblFwSize = totalFsblFwSize = data.len + ((4 - (data.len & 3)) & 3); + data.len += pmuFwSize; + + if (Load.IsSet()) + hdr->execAddress = Load.Value(); + } + hdr->partition = new Partition(hdr, data.bytes, data.len); hdr->partitionSize = data.len; partitionHeaderList.push_back(hdr); allows SPL to boot on ZynqMP: ./bootgen -arch zynqmp -image ./bif -w on -o boot.bin I'll try to get authentication with SPL going first on bootgen; then should be simple to port back to mkimage.