From: "José Miguel Gonçalves" <jose.goncalves@inov.pt>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH v4 10/11] Add u-boot-pad.bin target to the Makefile
Date: Fri, 21 Sep 2012 09:13:47 +0100 [thread overview]
Message-ID: <505C21BB.7000209@inov.pt> (raw)
In-Reply-To: <20120921054348.E7801203200@gemini.denx.de>
Hi Wolfgang,
On 09/21/2012 06:43 AM, Wolfgang Denk wrote:
> Dear Tom,
>
> In message <5FBF8E85CA34454794F0F7ECBA79798F379F6FD992@HQMAIL04.nvidia.com> you wrote:
>> If you flash u-boot-dtb-tegra.bin, you'll get a fully functioning
>> U-Boot. There's an intermediate file (u-boot-dtb.bin) that I assume
>> is u-boot.bin+dtb - I'm not sure why it's left around - Allen could
>> comment here.
> I _dislike_ the idea of having image names which include architecture
> or even board parts. I would really like to have generic names, that
> can be used in a consistent way across platforms, architectures and
> boards.
>
>> So in my eyes, all you really need is u-boot-dtb-tegra.bin - an
>> unwieldy name, to be sure, but it seems to satisfy your request for a
>> Soc identifier in the name. I voted for just having u-boot.bin be the
> Please reconsider. I definitely do NOT want to have SoC names or that
> in any such images!
>
>
> IIRC, the original idea was to provide image names (common for all
> architectures, SoCs, boards) that only depend on where you install
> U-Boot to. in this way, we would have:
>
> - u-boot.bin for the generic case (say, for installation into NOR
> flash, no SPL or similar needed).
> - u-boot-nand.bin
> for installation in NAND (with all needed headers,
> padding etc. included)
> - u-boot-onenand.bin
> for installation in OneNAND
> - u-boot.sd for installation on a SDCard
> [actually we have an inconsistency in names here; this
> should have been "u-boot-sd.bin" or maybe even better
> "u-boot-sdcard.bin"]
> etc.
>
> It is very important to me that we do NOT include any architectures,
> SoCs, or board specifc parts in the names because this will cause
> major PITA for all kind of automatic test suites etc.
>
To me this seems also a cleaner solution, as any end user, that simply
takes the u-boot sources and performs a make, would easily find the
appropriate file to burn on his boot media.
But in that case, as the NAND image format (for instance) is
architecture and/or SoC dependant, what do you suggest is to add
conditionals in the Makefile that adequate the 'u-boot-nand.bin' file to
the target SoC?
Best regards,
Jos? Gon?alves
next prev parent reply other threads:[~2012-09-21 8:13 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-19 11:25 [U-Boot] [PATCH v4 00/11] S3C24XX: Add support to MINI2416 board José Miguel Gonçalves
2012-09-19 11:25 ` [U-Boot] [PATCH v4 01/11] Add configuration option to select printf() inclusion on SPL José Miguel Gonçalves
2012-09-19 11:25 ` [U-Boot] [PATCH v4 02/11] S3C24XX: Add core support for Samsung's S3C24XX SoCs José Miguel Gonçalves
2012-09-19 11:25 ` [U-Boot] [PATCH v4 03/11] serial: Add support to 4 ports in serial_s3c24x0 José Miguel Gonçalves
2012-09-19 11:25 ` [U-Boot] [PATCH v4 04/11] serial: Use a more precise baud rate generation for serial_s3c24x0 José Miguel Gonçalves
2012-09-19 11:25 ` [U-Boot] [PATCH v4 05/11] serial: Remove unnecessary delay in serial_s3c24x0 José Miguel Gonçalves
2012-09-19 11:25 ` [U-Boot] [PATCH v4 06/11] rtc: Improve rtc_get() on s3c24x0_rtc José Miguel Gonçalves
2012-09-19 11:25 ` [U-Boot] [PATCH v4 07/11] rtc: Fix rtc_reset() " José Miguel Gonçalves
2012-09-19 11:25 ` [U-Boot] [PATCH v4 08/11] rtc: Don't allow setting unsuported years " José Miguel Gonçalves
2012-09-19 11:25 ` [U-Boot] [PATCH v4 09/11] S3C24XX: Add NAND Flash driver José Miguel Gonçalves
2012-09-19 16:19 ` Scott Wood
2012-09-19 16:34 ` José Miguel Gonçalves
2012-09-19 11:25 ` [U-Boot] [PATCH v4 10/11] Add u-boot-pad.bin target to the Makefile José Miguel Gonçalves
2012-09-19 16:10 ` Scott Wood
2012-09-19 16:58 ` José Miguel Gonçalves
2012-09-19 17:08 ` Scott Wood
2012-09-19 17:40 ` José Miguel Gonçalves
2012-09-19 17:11 ` Stephen Warren
2012-09-19 18:19 ` Tom Rini
2012-09-19 18:36 ` Scott Wood
2012-09-19 20:17 ` Tom Rini
2012-09-19 18:44 ` José Miguel Gonçalves
2012-09-19 22:39 ` Scott Wood
2012-09-19 23:31 ` Tom Rini
2012-09-19 23:36 ` Scott Wood
2012-09-19 23:40 ` Tom Rini
2012-09-20 0:38 ` José Miguel Gonçalves
2012-09-20 1:29 ` Tom Rini
2012-09-20 16:01 ` Tom Warren
2012-09-20 16:23 ` Tom Rini
2012-09-20 16:32 ` Tom Warren
2012-09-20 18:09 ` Scott Wood
2012-09-21 1:08 ` José Miguel Gonçalves
2012-09-21 5:43 ` Wolfgang Denk
2012-09-21 8:13 ` José Miguel Gonçalves [this message]
2012-09-21 15:52 ` Wolfgang Denk
2012-09-21 16:08 ` Marek Vasut
2012-09-21 16:13 ` Tom Rini
2012-09-21 16:26 ` José Miguel Gonçalves
2012-09-21 16:38 ` Tom Rini
2012-09-21 16:37 ` Langer Thomas
2012-09-21 18:33 ` Scott Wood
2012-09-21 18:43 ` Marek Vasut
2012-09-21 19:03 ` Scott Wood
2012-09-21 19:24 ` Marek Vasut
2012-09-21 19:33 ` Scott Wood
2012-09-23 16:25 ` Wolfgang Denk
2012-09-19 11:25 ` [U-Boot] [PATCH v4 11/11] S3C24XX: Add support to MINI2416 board José Miguel Gonçalves
2012-09-19 19:18 ` Tom Rini
2012-09-19 20:34 ` José Miguel Gonçalves
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=505C21BB.7000209@inov.pt \
--to=jose.goncalves@inov.pt \
--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