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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 82C7BC43334 for ; Mon, 25 Jul 2022 11:56:22 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id DF77884168; Mon, 25 Jul 2022 13:56:19 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=gmail.com 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=gmail.com header.i=@gmail.com header.b="dsChdc/j"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id A226084120; Mon, 25 Jul 2022 13:56:18 +0200 (CEST) Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com [IPv6:2a00:1450:4864:20::62d]) (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 03B4284120 for ; Mon, 25 Jul 2022 13:56:16 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=jbx6244@gmail.com Received: by mail-ej1-x62d.google.com with SMTP id j22so20127966ejs.2 for ; Mon, 25 Jul 2022 04:56:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to:content-transfer-encoding; bh=WsjPXo79JlS33NYORlSjEmeGwzLT0Qkyubx7vMRvVCA=; b=dsChdc/jesg28s61FeKcAnJxB+kKR2qbCNYaGtPTX1vCHtUUVVd/YtHUSqPfaa+bOf 4KMYjizybLw1MnU2Uxf00ZsxuSmzRZ0N02N4c+hMSBvG2lqMzbPrmjFEkFO2S3Gmv2eK HJkM+mtiQ2RQUC7bOsJwPyvbXXGaHCAOMcmAkM0sW2T1MNGfn9ayM5Yb5Sp6eBIbva0X CX5LUEtZ5NotvF8T5LAjb+EIx7Lz37o5+X4t7epa9IMPYNwQjR3Z6BZIgEApP68A/m28 +WfHmuZ6Qkp6mGaXdohiIm0zm32K5qYEl1i0CAVW99TIe2kvA1n1BvpQCTrYh/s8nUL8 4znA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=WsjPXo79JlS33NYORlSjEmeGwzLT0Qkyubx7vMRvVCA=; b=4QzikTZno1mDsoGBiPOqsV/ugN336PMLdiRmqFO0vIuA/rKVraiyEWyd7zfAA2s0yc RqRH/2PC2Jus0sx3wnyQAdWNpEzTkd7cvWHum5UGDCqMhcx/s8DWxfMsVy845omZZ0Xu 1p7NzzmapGlIpf7Crt58E/+KuADx3W5HI7YtjChOY/Xl7zQgSVuVJTlj1SSYK7HYadA8 YbRXIV1bUq/S6P4p+kmKZcSD5rr2iESCMu/uKpIxV8u962dJOX2PmelbwukzUO8Hd8Rl cgory2jD3+lez5WOr92uOH0oAt37FESk+6G1px5R4qH90TJYj/S2t8tMFlqC1PdVn0yb l9Kg== X-Gm-Message-State: AJIora+mCm0zMnAR9uiha/wBi1mOv+9I+/PWdU+q+1af26ki3GLfB0Fq kNs7wEPjwkgkDu66vNLWvrI= X-Google-Smtp-Source: AGRyM1tMfjDcKXc0IcAxG+GC0hHLlfj38jBCXEOjlxI+cAdGNgMPD4/CTX0qBwJV74YEAxxZPdPVug== X-Received: by 2002:a17:907:a0c6:b0:72f:2293:bd04 with SMTP id hw6-20020a170907a0c600b0072f2293bd04mr9964808ejc.123.1658750175507; Mon, 25 Jul 2022 04:56:15 -0700 (PDT) Received: from [192.168.2.2] (81-204-249-205.fixed.kpn.net. [81.204.249.205]) by smtp.gmail.com with ESMTPSA id s20-20020a05640217d400b0043baadb2279sm7157312edy.59.2022.07.25.04.56.14 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 25 Jul 2022 04:56:15 -0700 (PDT) Message-ID: <579b276e-732f-ebff-06d5-fa29f01c97d2@gmail.com> Date: Mon, 25 Jul 2022 13:56:12 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.0 Subject: Re: [PATCH v2 1/7] rockchip: generate idbloader.img content for u-boot-rockchip.bin with binman for ARM Content-Language: en-US To: Xavier Drudis Ferran , Quentin Schulz Cc: Quentin Schulz , bharat.gooty@broadcom.com, kever.yang@rock-chips.com, jagan@amarulasolutions.com, andy.yan@rock-chips.com, hl@rock-chips.com, chenjh@rock-chips.com, manivannan.sadhasivam@linaro.org, nick@khadas.com, klaus.goger@theobroma-systems.com, jernej.skrabec@gmail.com, deepakdas.linux@gmail.com, linux@alxd.me, mail@david-bauer.net, peterwillcn@gmail.com, u-boot@lists.denx.de References: <20220722113505.3875669-1-foss+uboot@0leil.net> <20220722113505.3875669-2-foss+uboot@0leil.net> <794bbfad-6579-ce3a-5faa-c8f758221196@gmail.com> <435a3e47-eb02-2543-e911-62e7c2cfe0c9@theobroma-systems.com> <20220725110529.GB2029@begut> From: Johan Jonker In-Reply-To: <20220725110529.GB2029@begut> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.39 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.6 at phobos.denx.de X-Virus-Status: Clean On 7/25/22 13:05, Xavier Drudis Ferran wrote: > Note: I removed a few recipients from Cc: with a quite random criteria, > just to avoid error messages from the list software that there were > too many addresses in Cc:. I hope those will get it from the list anyway > and sorry if this is a problem. > > >> I'm sure I'm just missing out on something obvious but cannot find it right >> now. >> I have an issue with the assumption of what u-boot-rockchip.bin is supposed >> to be. What does it actually represent? >> >> I have three possible boot media on my board: SPI-NOR, eMMC and SD Card. >> Both MMC devices can use the same offsets and images, so that's fine for me >> to have something like u-boot-rockchip-mmc.bin. >> However, SPI-NOR has a different offset for U-Boot proper than MMC devices. >> It would be ridiculous to have two defconfigs with the only difference being >> the value of SPL_PAD_TO option. Hence why there's a u-boot-rockchip-spi.bin >> image now and also why I argue in this patch series that using SPL_PAD_TO is >> incorrect. I replaced SPL_PAD_TO with the formula that was originally used >> to define the padding, see https://source.denx.de/u-boot/u-boot/-/commit/79030a486128bdb6888059113711a6ae66ff89c5. >> I understand this change is not ok, but I cannot use SPL_PAD_TO either. I >> would like to have some opinion/answer on what I asked in the paragraph >> above. > > The difference between u-boot-rockchip-mmc.bin and > u-boot-rockchip-spi.bin is not only the offset. The image for SPI has > the parts loaded by bootrom (tpl and spl) written in 8Kb chunks > separated by 8Kb empty space (or something like this, I don't > remember). That's why there are different -T rksd and -T rkspi > options to mkimage. This is so at least for RK3399. > > I have no idea whether nand images need this special format or not, > or whether it depends on the SoC model or what. If it's only the > offset, then maybe we can avoid a 3rd image and reuse the MMC one. > I don't know. > The pattern for NAND depends on the chip. Have NOT found a good logic for lsb modes other then a lookup list. No need for a 3rd image as idbloader.img contains everything (header/TPL/SPL/RC4 support) for further processing elsewhere. Johan