From: Xavier Drudis Ferran <xdrudis@tinet.cat>
To: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Cc: Johan Jonker <jbx6244@gmail.com>,
Quentin Schulz <foss+uboot@0leil.net>,
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
Subject: Re: [PATCH v2 1/7] rockchip: generate idbloader.img content for u-boot-rockchip.bin with binman for ARM
Date: Mon, 25 Jul 2022 13:05:29 +0200 [thread overview]
Message-ID: <20220725110529.GB2029@begut> (raw)
In-Reply-To: <435a3e47-eb02-2543-e911-62e7c2cfe0c9@theobroma-systems.com>
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.
next prev parent reply other threads:[~2022-07-25 11:06 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-22 11:34 [PATCH v2 0/7] migrate u-boot-rockchip.bin to binman and generate an image for SPI Quentin Schulz
2022-07-22 11:34 ` [PATCH v2 1/7] rockchip: generate idbloader.img content for u-boot-rockchip.bin with binman for ARM Quentin Schulz
2022-07-23 12:07 ` Johan Jonker
2022-07-23 18:04 ` Matwey V. Kornilov
2022-07-23 19:49 ` [SPAM] " Xavier Drudis Ferran
2022-07-25 10:25 ` Quentin Schulz
2022-07-25 11:05 ` Xavier Drudis Ferran [this message]
2022-07-25 11:56 ` Johan Jonker
2022-07-28 13:26 ` Jagan Teki
2022-07-22 11:35 ` [PATCH v2 2/7] rockchip: generate u-boot-rockchip.bin with binman for ARM64 boards Quentin Schulz
2022-07-22 11:35 ` [PATCH v2 3/7] rockchip: remove unneeded CONFIG_SPL_PAD_TO Quentin Schulz
2022-07-22 11:35 ` [PATCH v2 4/7] rockchip: simplify binman image dependencies addition to INPUTS Quentin Schulz
2022-07-22 11:35 ` [PATCH v2 5/7] rockchip: allow to build SPI images even without HAS_ROM option Quentin Schulz
2022-07-22 11:35 ` [PATCH v2 6/7] binman: add support for skipping file concatenation for mkimage Quentin Schulz
2022-07-22 11:35 ` [PATCH v2 7/7] rockchip: add u-boot-rockchip-spi.bin image for booting from SPI-NOR flash Quentin Schulz
2022-07-24 7:46 ` [SPAM] [PATCH v2 0/7] migrate u-boot-rockchip.bin to binman and generate an image for SPI Xavier Drudis Ferran
2022-07-25 10:54 ` Quentin Schulz
2022-07-25 11:20 ` Xavier Drudis Ferran
2022-07-25 16:39 ` Quentin Schulz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220725110529.GB2029@begut \
--to=xdrudis@tinet.cat \
--cc=andy.yan@rock-chips.com \
--cc=bharat.gooty@broadcom.com \
--cc=chenjh@rock-chips.com \
--cc=deepakdas.linux@gmail.com \
--cc=foss+uboot@0leil.net \
--cc=hl@rock-chips.com \
--cc=jagan@amarulasolutions.com \
--cc=jbx6244@gmail.com \
--cc=jernej.skrabec@gmail.com \
--cc=kever.yang@rock-chips.com \
--cc=klaus.goger@theobroma-systems.com \
--cc=linux@alxd.me \
--cc=mail@david-bauer.net \
--cc=manivannan.sadhasivam@linaro.org \
--cc=nick@khadas.com \
--cc=peterwillcn@gmail.com \
--cc=quentin.schulz@theobroma-systems.com \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox