From: Alper Nebi Yasak <alpernebiyasak@gmail.com>
To: Andrew Abbott <andrew@mirx.dev>
Cc: Jagan Teki <jagan@amarulasolutions.com>,
Johan Jonker <jbx6244@gmail.com>, Simon Glass <sjg@chromium.org>,
Samuel Dionne-Riel <samuel@dionne-riel.com>,
Peter Robinson <pbrobinson@gmail.com>,
Kever Yang <kever.yang@rock-chips.com>,
Philipp Tomsich <philipp.tomsich@vrull.eu>,
U-Boot Mailing List <u-boot@lists.denx.de>
Subject: Re: [RFC PATCH v2 2/8] rockchip: Add binman definitions for final images
Date: Sun, 29 May 2022 19:31:17 +0300 [thread overview]
Message-ID: <d0387241-5f06-083f-e920-e4dee44dc544@gmail.com> (raw)
In-Reply-To: <CK5VPYTCMYN9.28FVH5ECWWCU9@sapphire>
On 22/05/2022 03:55, Andrew Abbott wrote:
> On Thu May 19, 2022 at 9:36 PM AEST, Alper Nebi Yasak wrote:
>> Do we need the 'idbloader.img' as a build output, assuming we have a
>> working 'u-boot-rockchip.bin'? I'm asking because Simon was trying to
>> drop it in a similar patch [1].
>
> I was keeping it for backwards compatibility, mainly because it's
> mentioned in 'rockchip.rst' and it implies that 'idbloader.img' goes
> on a separate partition to 'u-boot.itb' for targets supporting Fastboot.
> If we can drop it, then I'll gladly do so!
Honestly, I don't know. I was hoping someone else would comment as well.
I'm inclined to say we don't need it, as we would ideally be able to
extract/replace the 'idbloader.img' from/in working images with binman
commands when needed.
>> With what I said above, I think you should rename this to 'u-boot.rom'
>> and remove the definitions in {rk3288,rk3399}-u-boot.dtsi.
>
> Makes sense to me - I just wonder if the name 'u-boot.rom' is too
> generic, since it will be an image specifically for Rockchip targets.
> Then again, perhaps the original 'u-boot-rockchip.bin' name was
> redundant, since you know what target you're building for by using a
> specific defconfig in the first place.
I think it's meant to be a step towards unifying the build artifacts and
names across the board, which I'd like if it eventually happened. We
would have different definitions of the 'u-boot.rom' image for different
whatevers, but for every board "Build and write u-boot.rom to SPI flash
if it exists" would be valid advice.
next prev parent reply other threads:[~2022-05-29 16:31 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-16 11:07 [RFC PATCH v2 0/8] Build Rockchip final images using binman Andrew Abbott
2022-05-16 11:07 ` [RFC PATCH v2 1/8] binman: mkimage: Support ':'-separated inputs Andrew Abbott
2022-05-19 11:36 ` Alper Nebi Yasak
2022-05-22 0:03 ` Andrew Abbott
2022-05-16 11:07 ` [RFC PATCH v2 2/8] rockchip: Add binman definitions for final images Andrew Abbott
2022-05-19 11:36 ` Alper Nebi Yasak
2022-05-22 0:55 ` Andrew Abbott
2022-05-29 16:31 ` Alper Nebi Yasak [this message]
2022-05-16 11:07 ` [RFC PATCH v2 3/8] soc: rockchip: Include common U-Boot dtsi file Andrew Abbott
2022-05-19 11:36 ` Alper Nebi Yasak
2022-05-16 11:07 ` [RFC PATCH v2 4/8] board: rockchip: Move SPI U-Boot offset to config Andrew Abbott
2022-05-19 11:36 ` Alper Nebi Yasak
2022-05-16 11:07 ` [RFC PATCH v2 5/8] rockchip: Remove obsolete Makefile targets Andrew Abbott
2022-05-16 11:07 ` [RFC PATCH v2 6/8] rockchip: Enable binman for ARM64 Andrew Abbott
2022-05-19 11:37 ` Alper Nebi Yasak
2022-05-22 1:27 ` Andrew Abbott
2022-05-16 11:07 ` [RFC PATCH v2 7/8] doc: rockchip: Update for new binman image generation Andrew Abbott
2022-05-16 11:07 ` [RFC PATCH v2 8/8] board: rockpro64: Enable building SPI image Andrew Abbott
2022-05-16 15:13 ` [RFC PATCH v2 0/8] Build Rockchip final images using binman Jerome Forissier
2022-05-19 9:59 ` Andrew Abbott
2022-05-19 11:35 ` Alper Nebi Yasak
2022-05-21 23:47 ` Andrew Abbott
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=d0387241-5f06-083f-e920-e4dee44dc544@gmail.com \
--to=alpernebiyasak@gmail.com \
--cc=andrew@mirx.dev \
--cc=jagan@amarulasolutions.com \
--cc=jbx6244@gmail.com \
--cc=kever.yang@rock-chips.com \
--cc=pbrobinson@gmail.com \
--cc=philipp.tomsich@vrull.eu \
--cc=samuel@dionne-riel.com \
--cc=sjg@chromium.org \
--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