All of lore.kernel.org
 help / color / mirror / Atom feed
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.

  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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.