S3C24XX: Add support to MINI2416 board

NAND Flash driver with HW ECC for the S3C24XX SoCs. Currently it only supports SLC NAND chips.

Signed-off-by Jos? Miguel Gon?alves <[email protected]>

---
Changes for v2:
- Coding style cleanup
- Use of clrsetbits_le32()
- Use of register bit macros instead of magic numbers

Changes for v3:
- Removed magic numbers
- Removed a macro to declare a void printf()
- Replaced one printf() with a puts()

Changes for v4:
- Coding style cleanup
- Use of a struct to store chip private data
- Replaced u_long by u32
- Replaced u_char by uint8_t
- Added error message in s3c_nand_select_chip()
- Optimization of s3c_nand_hwcontrol()

---
 drivers/mtd/nand/Makefile       |    1 +
 drivers/mtd/nand/s3c24xx_nand.c |  255  
+++++++++++++++++++++++++++++++++++++++
 2 files changed, 256 insertions(+)
 create mode 100644 drivers/mtd/nand/s3c24xx_nand.c

Quoted 22 lines · Jos? Miguel Gon?alves

NAND Flash driver with HW ECC for the S3C24XX SoCs. Currently it only supports SLC NAND chips.

Signed-off-by Jos? Miguel Gon?alves <[email protected]>

---
Changes for v2:
- Coding style cleanup
- Use of clrsetbits_le32()
- Use of register bit macros instead of magic numbers

Changes for v3:
- Removed magic numbers
- Removed a macro to declare a void printf()
- Replaced one printf() with a puts()

Changes for v4:
- Coding style cleanup
- Use of a struct to store chip private data
- Replaced u_long by u32
- Replaced u_char by uint8_t
- Added error message in s3c_nand_select_chip()
- Optimization of s3c_nand_hwcontrol()

Quoted 5 lines

---
 drivers/mtd/nand/Makefile       |    1 +
 drivers/mtd/nand/s3c24xx_nand.c |  255 +++++++++++++++++++++++++++++++++++++++
 2 files changed, 256 insertions(+)
 create mode 100644 drivers/mtd/nand/s3c24xx_nand.c

Acked-by Scott Wood <[email protected]>

Quoted 1 line

+ nand->priv = (void *)&chip_info[chip_n++];

Hmm, I was going to say that the cast could be dropped, but I guess it's because of the const.

It doesn't need to hold up acceptance of the patch, but it'd probably be better to drop the const instead (more flexible too if additional private data needs to be declared).

Samsung's S3C24XX SoCs need this in order to generate a binary image with a padded SPL concatenated with U-Boot.

Quoted 2 lines · Jos? Miguel Gon?alves

Samsung's S3C24XX SoCs need this in order to generate a binary image with a padded SPL concatenated with U-Boot.

I still think "pad" is a lousy name for this. It refers to a minor implementation detail of how the image was put together.

If you don't like the suggestions in
http://lists.denx.de/pipermail/u-boot/2012-September/134191.html, how about "u-boot-with-spl.bin"?

Quoted 11 lines · Scott Wood

Quoted 2 lines · Jos? Miguel Gon?alves

Samsung's S3C24XX SoCs need this in order to generate a binary image with a padded SPL concatenated with U-Boot.

I still think "pad" is a lousy name for this. It refers to a minor implementation detail of how the image was put together.

If you don't like the suggestions in
http://lists.denx.de/pipermail/u-boot/2012-September/134191.html,
how about
"u-boot-with-spl.bin"?

I used a suggestion made by Christian Riesch and accepted by Tom Rini.

I'm totally cool with any name that the U-Boot core maintainers would like to use, though I would prefer a shorter name than "u-boot-with-spl.bin" because I'm lazy and don't like to type too many keys when I upgrade by tftp :-) Because of that I think I would prefer "u-boot-all.bin". So, everybody agrees with that name?

Quoted 12 lines · Jos? Miguel Gon?alves

Quoted 10 lines · Scott Wood

Quoted 2 lines · Jos? Miguel Gon?alves

Samsung's S3C24XX SoCs need this in order to generate a binary image with a padded SPL concatenated with U-Boot.

I still think "pad" is a lousy name for this. It refers to a minor implementation detail of how the image was put together.

If you don't like the suggestions in
http://lists.denx.de/pipermail/u-boot/2012-September/134191.html, how about "u-boot-with-spl.bin"?

Quoted 7 lines

I used a suggestion made by Christian Riesch and accepted by Tom Rini.

I'm totally cool with any name that the U-Boot core maintainers would like to use, though I would prefer a shorter name than "u-boot-with-spl.bin" because I'm lazy and don't like to type too many keys when I upgrade by tftp :-) Because of that I think I would prefer "u-boot-all.bin". So, everybody agrees with that name?

setenv uboot pathname/u-boot-with-as-much-verbosity-as-you-want.bin setenv tftpnand 'tftp $loadaddr $uboot && nand erase 0 $filesize && nand write $loadaddr 0 $filesize'
saveenv
run tftpnand

Quoted 11 lines · Scott Wood

Quoted 2 lines · Jos? Miguel Gon?alves

Samsung's S3C24XX SoCs need this in order to generate a binary image with a padded SPL concatenated with U-Boot.

I still think "pad" is a lousy name for this. It refers to a minor implementation detail of how the image was put together.

If you don't like the suggestions in
http://lists.denx.de/pipermail/u-boot/2012-September/134191.html, how about
"u-boot-with-spl.bin"?

I used a suggestion made by Christian Riesch and accepted by Tom Rini.

I'm totally cool with any name that the U-Boot core maintainers would like to use, though I would prefer a shorter name than "u-boot-with-spl.bin" because I'm lazy and don't like to type too many keys when I upgrade by tftp :-) Because of that I think I would prefer "u-boot-all.bin". So, everybody agrees with that name?

Quoted 8 lines · Jos? Miguel Gon?alves

Quoted 7 lines · Scott Wood

Quoted 2 lines · Jos? Miguel Gon?alves

Samsung's S3C24XX SoCs need this in order to generate a binary image with a padded SPL concatenated with U-Boot.

I still think "pad" is a lousy name for this. It refers to a minor implementation detail of how the image was put together.

Quoted 6 lines

Quoted 4 lines

If you don't like the suggestions in
http://lists.denx.de/pipermail/u-boot/2012-September/134191.html, how about
"u-boot-with-spl.bin"?

I used a suggestion made by Christian Riesch and accepted by Tom Rini.

Quoted 5 lines

I'm totally cool with any name that the U-Boot core maintainers would like to use, though I would prefer a shorter name than "u-boot-with-spl.bin" because I'm lazy and don't like to type too many keys when I upgrade by tftp :-) Because of that I think I would prefer "u-boot-all.bin". So, everybody agrees with that name?

Hmmm. What does "all" mean? It's not that descriptive.

On Tegra we currently have:

u-boot-spl.bin - just SPL.
u-boot.bin - just main U-Boot, I think. u-boot-dtb.bin - main U-Boot plus an appended DTB, I think. u-boot-dtb-tegra.bin - SPL+U-Boot+DTB.

Quoted 4 lines · Stephen Warren

Quoted 3 lines · Jos? Miguel Gon?alves

Quoted 2 lines · Scott Wood

Quoted 1 line · Jos? Miguel Gon?alves

Samsung's S3C24XX SoCs need this in order to generate a binary

image

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 1 line

with a padded SPL concatenated with U-Boot.

I still think "pad" is a lousy name for this. It refers to a

minor

Quoted 4 lines

Quoted 4 lines

Quoted 4 lines

implementation detail of how the image was put together.

If you don't like the suggestions in

http://lists.denx.de/pipermail/u-boot/2012-September/134191.html, how

Quoted 4 lines

Quoted 4 lines

Quoted 2 lines

about
"u-boot-with-spl.bin"?

I used a suggestion made by Christian Riesch and accepted by Tom

Rini.

Sorry for the churn, really, but..

Quoted 1 line

Quoted 1 line

I'm totally cool with any name that the U-Boot core maintainers

would

Quoted 2 lines

Quoted 2 lines

like to use, though I would prefer a shorter name than "u-boot-with-spl.bin" because I'm lazy and don't like to type too

many

Quoted 1 line

Quoted 1 line

keys when I upgrade by tftp :-) Because of that I think I would

prefer

Quoted 10 lines

Quoted 1 line

"u-boot-all.bin". So, everybody agrees with that name?

Hmmm. What does "all" mean? It's not that descriptive.

On Tegra we currently have:

u-boot-spl.bin - just SPL.
u-boot.bin - just main U-Boot, I think. u-boot-dtb.bin - main U-Boot plus an appended DTB, I think. u-boot-dtb-tegra.bin - SPL+U-Boot+DTB.

As this, and other examples show, there's not really good generic names.
Go with u-boot.s3c24xx as the target and output, please. This is consistent with the other targets and outputs where we throw something that identifies the SoC/etc into the target/name.

Quoted 42 lines · Tom Rini

Quoted 4 lines · Stephen Warren

Quoted 3 lines · Jos? Miguel Gon?alves

Quoted 2 lines · Scott Wood

Quoted 1 line · Jos? Miguel Gon?alves

Samsung's S3C24XX SoCs need this in order to generate a

binary image

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 1 line

with a padded SPL concatenated with U-Boot.

I still think "pad" is a lousy name for this. It refers to a

minor

Quoted 4 lines

Quoted 4 lines

Quoted 4 lines

implementation detail of how the image was put together.

If you don't like the suggestions in

http://lists.denx.de/pipermail/u-boot/2012-September/134191.html,
how

Quoted 4 lines

Quoted 4 lines

Quoted 2 lines

about
"u-boot-with-spl.bin"?

I used a suggestion made by Christian Riesch and accepted by

Tom Rini.

Sorry for the churn, really, but..

Quoted 1 line

Quoted 1 line

I'm totally cool with any name that the U-Boot core

maintainers would

Quoted 2 lines

Quoted 2 lines

like to use, though I would prefer a shorter name than "u-boot-with-spl.bin" because I'm lazy and don't like to type

too many

Quoted 1 line

Quoted 1 line

keys when I upgrade by tftp :-) Because of that I think I

would prefer

Quoted 10 lines

Quoted 1 line

"u-boot-all.bin". So, everybody agrees with that name?

Hmmm. What does "all" mean? It's not that descriptive.

On Tegra we currently have:

u-boot-spl.bin - just SPL.
u-boot.bin - just main U-Boot, I think. u-boot-dtb.bin - main U-Boot plus an appended DTB, I think. u-boot-dtb-tegra.bin - SPL+U-Boot+DTB.

Quoted 5 lines

As this, and other examples show, there's not really good generic names.
Go with u-boot.s3c24xx as the target and output, please. This is consistent with the other targets and outputs where we throw something that identifies the SoC/etc into the target/name.

So we're just going to duplicate this rule with a different name for every target that just needs a simple concatenation? Like the bad old days of having a rule for every target in the makefile? Come on.

Plus, I don't like using a semi-generic name in the output file because it then looks to the user as if this is a U-Boot that covers that entire family of devices, rather than just the target it was built for. At least with fully generic names like "u-boot.bin" it should be obvious to most people that it doesn't cover every single target. If we must have a non-generic output name, base it on the actual target name using a pattern rule -- but I do not see what's wrong with a generic name. Not necessarily something that works for every target -- that's a strawman -- just something that describes the output of this rule in a way that isn't overly specific.

Quoted 5 lines · Stephen Warren

Quoted 4 lines · Jos? Miguel Gon?alves

Quoted 3 lines · Scott Wood

Quoted 2 lines · Jos? Miguel Gon?alves

Samsung's S3C24XX SoCs need this in order to generate a binary image with a padded SPL concatenated with U-Boot.

Quoted 8 lines

Quoted 8 lines

Quoted 7 lines

I still think "pad" is a lousy name for this. It refers to a minor implementation detail of how the image was put together.

If you don't like the suggestions in
http://lists.denx.de/pipermail/u-boot/2012-September/134191.html, how about
"u-boot-with-spl.bin"?

I used a suggestion made by Christian Riesch and accepted by Tom Rini.

Sorry for the churn, really, but..

Quoted 9 lines

Quoted 5 lines

I'm totally cool with any name that the U-Boot core maintainers would like to use, though I would prefer a shorter name than "u-boot-with-spl.bin" because I'm lazy and don't like to type too many keys when I upgrade by tftp :-) Because of that I think I would prefer "u-boot-all.bin". So, everybody agrees with that name?

Hmmm. What does "all" mean? It's not that descriptive.

On Tegra we currently have:

Quoted 4 lines

u-boot-spl.bin - just SPL.
u-boot.bin - just main U-Boot, I think. u-boot-dtb.bin - main U-Boot plus an appended DTB, I think. u-boot-dtb-tegra.bin - SPL+U-Boot+DTB.

As this, and other examples show, there's not really good generic names. Go with u-boot.s3c24xx as the target and output, please. This is consistent with the other targets and outputs where we throw something that identifies the SoC/etc into the target/name.

Samsung's S3C24XX SoCs need this in order to generate a binary image with a padded SPL concatenated with U-Boot.

Signed-off-by Jos? Miguel Gon?alves <[email protected]>

---
Changes for v2:
- None

Changes for v3:
- Changed new binary target name from u-boot-ubl.bin to
u-boot-pad.bin

Changes for v4:
- None

---
 Makefile |   11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)

Makefile +1 -1

index 8738d55..86dedca 100644
@@ -433,14 +433,15 @@ $(obj)u-boot.sha1:	$(obj)u-boot.bin
 $(obj)u-boot.dis:	$(obj)u-boot
 		$(OBJDUMP) -d $< > $@
 
-$(obj)u-boot.ubl:       $(obj)spl/u-boot-spl.bin $(obj)u-boot.bin
+$(obj)u-boot-pad.bin:       $(obj)spl/u-boot-spl.bin $(obj)u-boot.bin
 		$(OBJCOPY) ${OBJCFLAGS} --pad-to=$(PAD_TO) -O binary  

$(obj)spl/u-boot-spl $(obj)spl/u-boot-spl-pad.bin

Makefile +0 -1

-		cat $(obj)spl/u-boot-spl-pad.bin $(obj)u-boot.bin >  

$(obj)u-boot-ubl.bin

Makefile +0 -2

-		$(obj)tools/mkimage -n $(UBL_CONFIG) -T ublimage \
-		-e $(CONFIG_SYS_TEXT_BASE) -d $(obj)u-boot-ubl.bin  

$(obj)u-boot.ubl

Makefile +1 -1

-		rm $(obj)u-boot-ubl.bin
+		cat $(obj)spl/u-boot-spl-pad.bin $(obj)u-boot.bin >  

$(obj)u-boot-pad.bin
rm $(obj)spl/u-boot-spl-pad.bin

Quoted 17 lines · Jos? Miguel Gon?alves

Samsung's S3C24XX SoCs need this in order to generate a binary image with a padded SPL concatenated with U-Boot.

Signed-off-by Jos? Miguel Gon?alves <[email protected]>

--- Changes for v2: - None

Changes for v3: - Changed new binary target name from u-boot-ubl.bin to u-boot-pad.bin

Changes for v4: - None --- Makefile | 11 ++++++----- 1 file
changed, 6 insertions(+), 5 deletions(-)

Makefile index 8738d55..86dedca 100644 renamed from Makefile +0 -1

--- a/Makefile +++ b/Makefile @@ -433,14 +433,15 @@

$(obj)u-boot.sha1: $(obj)u-boot.bin $(obj)u-boot.dis:
$(obj)u-boot $(OBJDUMP) -d $< > $@

Quoted 12 lines

-$(obj)u-boot.ubl: $(obj)spl/u-boot-spl.bin
$(obj)u-boot.bin +$(obj)u-boot-pad.bin:
$(obj)spl/u-boot-spl.bin $(obj)u-boot.bin $(OBJCOPY) ${OBJCFLAGS} --pad-to=$(PAD_TO) -O binary $(obj)spl/u-boot-spl
$(obj)spl/u-boot-spl-pad.bin - cat
$(obj)spl/u-boot-spl-pad.bin $(obj)u-boot.bin >
$(obj)u-boot-ubl.bin - $(obj)tools/mkimage -n
$(UBL_CONFIG) -T ublimage \ - -e $(CONFIG_SYS_TEXT_BASE)
-d $(obj)u-boot-ubl.bin $(obj)u-boot.ubl - rm
$(obj)u-boot-ubl.bin + cat $(obj)spl/u-boot-spl-pad.bin
$(obj)u-boot.bin > $(obj)u-boot-pad.bin rm $(obj)spl/u-boot-spl-pad.bin

This rule lists u-boot-spl.bin as a prerequisite, but it doesn't appear to use it -- it uses u-boot-spl instead.

It seems that either spl/Makefile should produce u-boot-spl rather than u-boot-spl.bin and let the toplevel Makefile deal with converting it to a binary, or spl/Makefile should take care of adding any needed padding for the target and the final rule should just be a concatenation.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Quoted 34 lines · Scott Wood

Quoted 17 lines · Jos? Miguel Gon?alves

Samsung's S3C24XX SoCs need this in order to generate a binary image with a padded SPL concatenated with U-Boot.

Signed-off-by Jos? Miguel Gon?alves <[email protected]>

--- Changes for v2: - None

Changes for v3: - Changed new binary target name from u-boot-ubl.bin to u-boot-pad.bin

Changes for v4: - None --- Makefile | 11 ++++++----- 1 file
changed, 6 insertions(+), 5 deletions(-)

Makefile index 8738d55..86dedca 100644 renamed from Makefile +0 -1

--- a/Makefile +++ b/Makefile @@ -433,14 +433,15 @@

$(obj)u-boot.sha1: $(obj)u-boot.bin $(obj)u-boot.dis:
$(obj)u-boot $(OBJDUMP) -d $< > $@

Quoted 12 lines

-$(obj)u-boot.ubl: $(obj)spl/u-boot-spl.bin
$(obj)u-boot.bin +$(obj)u-boot-pad.bin:
$(obj)spl/u-boot-spl.bin $(obj)u-boot.bin $(OBJCOPY) ${OBJCFLAGS} --pad-to=$(PAD_TO) -O binary $(obj)spl/u-boot-spl
$(obj)spl/u-boot-spl-pad.bin - cat
$(obj)spl/u-boot-spl-pad.bin $(obj)u-boot.bin >
$(obj)u-boot-ubl.bin - $(obj)tools/mkimage -n
$(UBL_CONFIG) -T ublimage \ - -e $(CONFIG_SYS_TEXT_BASE)
-d $(obj)u-boot-ubl.bin $(obj)u-boot.ubl - rm
$(obj)u-boot-ubl.bin + cat $(obj)spl/u-boot-spl-pad.bin
$(obj)u-boot.bin > $(obj)u-boot-pad.bin rm $(obj)spl/u-boot-spl-pad.bin

This rule lists u-boot-spl.bin as a prerequisite, but it doesn't appear to use it -- it uses u-boot-spl instead.

Quoted 5 lines

It seems that either spl/Makefile should produce u-boot-spl rather than u-boot-spl.bin and let the toplevel Makefile deal with converting it to a binary, or spl/Makefile should take care of adding any needed padding for the target and the final rule should just be a concatenation.

So, if we use a weak PAD_TO value of say 0x1, we could always "pad" u-boot-spl.bin out and then do the concatenation here and in a few other targets as well.

Quoted 43 lines · Tom Rini

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Quoted 39 lines · Scott Wood

Quoted 17 lines · Jos? Miguel Gon?alves

Samsung's S3C24XX SoCs need this in order to generate a binary image with a padded SPL concatenated with U-Boot.

Signed-off-by Jos? Miguel Gon?alves <[email protected]>

--- Changes for v2: - None

Changes for v3: - Changed new binary target name from u-boot-ubl.bin to u-boot-pad.bin

Changes for v4: - None --- Makefile | 11 ++++++----- 1 file
changed, 6 insertions(+), 5 deletions(-)

Makefile index 8738d55..86dedca renamed from Makefile +0 -0

100644 --- a/Makefile +++ b/Makefile @@ -433,14 +433,15 @@
$(obj)u-boot.sha1: $(obj)u-boot.bin $(obj)u-boot.dis:
$(obj)u-boot $(OBJDUMP) -d $< > $@

Quoted 12 lines

-$(obj)u-boot.ubl: $(obj)spl/u-boot-spl.bin
$(obj)u-boot.bin +$(obj)u-boot-pad.bin:
$(obj)spl/u-boot-spl.bin $(obj)u-boot.bin $(OBJCOPY) ${OBJCFLAGS} --pad-to=$(PAD_TO) -O binary $(obj)spl/u-boot-spl $(obj)spl/u-boot-spl-pad.bin - cat $(obj)spl/u-boot-spl-pad.bin $(obj)u-boot.bin >
$(obj)u-boot-ubl.bin - $(obj)tools/mkimage -n
$(UBL_CONFIG) -T ublimage \ - -e
$(CONFIG_SYS_TEXT_BASE) -d $(obj)u-boot-ubl.bin
$(obj)u-boot.ubl - rm $(obj)u-boot-ubl.bin + cat
$(obj)spl/u-boot-spl-pad.bin $(obj)u-boot.bin > $(obj)u-boot-pad.bin rm $(obj)spl/u-boot-spl-pad.bin

This rule lists u-boot-spl.bin as a prerequisite, but it doesn't appear to use it -- it uses u-boot-spl instead.

It seems that either spl/Makefile should produce u-boot-spl rather than u-boot-spl.bin and let the toplevel Makefile deal with converting it to a binary, or spl/Makefile should take care of adding any needed padding for the target and the final rule should just be a concatenation.

Quoted 3 lines

So, if we use a weak PAD_TO value of say 0x1, we could always "pad" u-boot-spl.bin out and then do the concatenation here and in a few other targets as well.

Yes, or use a variable that includes the linker option, so that it
expands to an empty string if padding isn't required.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Quoted 45 lines · Scott Wood

Quoted 44 lines · Tom Rini

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Quoted 33 lines · Scott Wood

Quoted 17 lines · Jos? Miguel Gon?alves

Samsung's S3C24XX SoCs need this in order to generate a binary image with a padded SPL concatenated with U-Boot.

Signed-off-by Jos? Miguel Gon?alves <[email protected]>

--- Changes for v2: - None

Changes for v3: - Changed new binary target name from u-boot-ubl.bin to u-boot-pad.bin

Changes for v4: - None --- Makefile | 11 ++++++----- 1 file
changed, 6 insertions(+), 5 deletions(-)

Makefile index 8738d55..86dedca renamed from Makefile +0 -0

100644 --- a/Makefile +++ b/Makefile @@ -433,14 +433,15 @@
$(obj)u-boot.sha1: $(obj)u-boot.bin $(obj)u-boot.dis:
$(obj)u-boot $(OBJDUMP) -d $< > $@

Quoted 12 lines

-$(obj)u-boot.ubl: $(obj)spl/u-boot-spl.bin
$(obj)u-boot.bin +$(obj)u-boot-pad.bin:
$(obj)spl/u-boot-spl.bin $(obj)u-boot.bin $(OBJCOPY) ${OBJCFLAGS} --pad-to=$(PAD_TO) -O binary $(obj)spl/u-boot-spl $(obj)spl/u-boot-spl-pad.bin - cat $(obj)spl/u-boot-spl-pad.bin $(obj)u-boot.bin >
$(obj)u-boot-ubl.bin - $(obj)tools/mkimage -n
$(UBL_CONFIG) -T ublimage \ - -e
$(CONFIG_SYS_TEXT_BASE) -d $(obj)u-boot-ubl.bin
$(obj)u-boot.ubl - rm $(obj)u-boot-ubl.bin + cat
$(obj)spl/u-boot-spl-pad.bin $(obj)u-boot.bin > $(obj)u-boot-pad.bin rm $(obj)spl/u-boot-spl-pad.bin

This rule lists u-boot-spl.bin as a prerequisite, but it doesn't appear to use it -- it uses u-boot-spl instead.

Quoted 5 lines

It seems that either spl/Makefile should produce u-boot-spl rather than u-boot-spl.bin and let the toplevel Makefile deal with converting it to a binary, or spl/Makefile should take care of adding any needed padding for the target and the final rule should just be a concatenation.

So, if we use a weak PAD_TO value of say 0x1, we could always "pad" u-boot-spl.bin out and then do the concatenation here and in a few other targets as well.

Quoted 2 lines

Yes, or use a variable that includes the linker option, so that it
expands to an empty string if padding isn't required.

Yes, I don't know if say IMAGE_PAD ?= "" and having boards set that to
- --pad-to=... or just saying --pad-to=$(PAD_SIZE) and PAD_SIZE ?= 0x1 ends up looking cleaner once all is said and done. First one to try both and patch... :)

Tom & Scott,

Quoted 49 lines · Tom Rini

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Quoted 46 lines · Scott Wood

Quoted 45 lines · Tom Rini

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Quoted 33 lines · Scott Wood

Quoted 17 lines · Jos? Miguel Gon?alves

Samsung's S3C24XX SoCs need this in order to generate a binary image with a padded SPL concatenated with U-Boot.

Signed-off-by: Jos? Miguel Gon?alves <[email protected]> --- Changes for v2: - None

Changes for v3: - Changed new binary target name from u-boot-ubl.bin to u-boot-pad.bin

Changes for v4: - None --- Makefile | 11 ++++++----- 1
file changed, 6 insertions(+), 5 deletions(-)

Makefile index 8738d55..86dedca renamed from Makefile +0 -0

100644 --- a/Makefile +++ b/Makefile @@ -433,14 +433,15
@@ $(obj)u-boot.sha1: $(obj)u-boot.bin
$(obj)u-boot.dis: $(obj)u-boot $(OBJDUMP) -d $< > $@

Quoted 12 lines

-$(obj)u-boot.ubl: $(obj)spl/u-boot-spl.bin
$(obj)u-boot.bin +$(obj)u-boot-pad.bin:
$(obj)spl/u-boot-spl.bin $(obj)u-boot.bin $(OBJCOPY) ${OBJCFLAGS} --pad-to=$(PAD_TO) -O binary $(obj)spl/u-boot-spl $(obj)spl/u-boot-spl-pad.bin - cat $(obj)spl/u-boot-spl-pad.bin $(obj)u-boot.bin >
$(obj)u-boot-ubl.bin - $(obj)tools/mkimage -n
$(UBL_CONFIG) -T ublimage \ - -e
$(CONFIG_SYS_TEXT_BASE) -d $(obj)u-boot-ubl.bin
$(obj)u-boot.ubl - rm $(obj)u-boot-ubl.bin + cat
$(obj)spl/u-boot-spl-pad.bin $(obj)u-boot.bin > $(obj)u-boot-pad.bin rm $(obj)spl/u-boot-spl-pad.bin

This rule lists u-boot-spl.bin as a prerequisite, but it doesn't appear to use it -- it uses u-boot-spl instead.

Quoted 6 lines

It seems that either spl/Makefile should produce u-boot-spl rather than u-boot-spl.bin and let the toplevel Makefile deal with converting it to a binary, or spl/Makefile should take care of adding any needed padding for the target and the final rule should just be a concatenation.

So, if we use a weak PAD_TO value of say 0x1, we could always "pad" u-boot-spl.bin out and then do the concatenation here and in a few other targets as well.

Quoted 7 lines

Quoted 2 lines

Yes, or use a variable that includes the linker option, so that it expands to an empty string if padding isn't required.

Yes, I don't know if say IMAGE_PAD ?= "" and having boards set that to - --pad-to=... or just saying --pad-to=$(PAD_SIZE) and PAD_SIZE ?= 0x1 ends up looking cleaner once all is said and done. First one to try both and patch... :)

Please check the following patch. It seems to work for me...

Makefile index 8738d55..fad8b33 100644 --- renamed from Makefile +0 -0

a/Makefile +++ b/Makefile @@ -433,13 +433,12 @@ $(obj)u-boot.sha1:
$(obj)u-boot.bin $(obj)u-boot.dis: $(obj)u-boot $(OBJDUMP) -d $<

Quoted 1 line

$@

-$(obj)u-boot.ubl: $(obj)spl/u-boot-spl.bin $(obj)u-boot.bin
- $(OBJCOPY) ${OBJCFLAGS} --pad-to=$(PAD_TO) -O binary
$(obj)spl/u-boot-spl $(obj)spl/u-boot-spl-pad.bin - cat
$(obj)spl/u-boot-spl-pad.bin $(obj)u-boot.bin > $(obj)u-boot-ubl.bin +$(obj)u-boot-with-spl.bin:
$(obj)spl/u-boot-spl.bin $(obj)u-boot.bin + cat $^ > $@ +
+$(obj)u-boot.ubl: $(obj)u-boot-with-spl.bin
$(obj)tools/mkimage -n $(UBL_CONFIG) -T ublimage \ - -e
$(CONFIG_SYS_TEXT_BASE) -d $(obj)u-boot-ubl.bin $(obj)u-boot.ubl -
rm $(obj)u-boot-ubl.bin - rm $(obj)spl/u-boot-spl-pad.bin +
-e $(CONFIG_SYS_TEXT_BASE) -d $< $@

$(obj)u-boot.ais: $(obj)spl/u-boot-spl.bin $(obj)u-boot.img
$(obj)tools/mkimage -s -n /dev/null -T aisimage \ diff --git a/spl/Makefile b/spl/Makefile index f96c08e..6ea9f26 100644 --- a/spl/Makefile +++ b/spl/Makefile @@ -23,6 +23,8 @@ include $(TOPDIR)/config.mk # We want the final binaries in this directory obj := $(OBJTREE)/spl/

+PAD_TO ?= 1 + HAVE_VENDOR_COMMON_LIB := $(shell [ -f $(SRCTREE)/board/$(VENDOR)/common/Makefile ] \ && echo y || echo
n)

Makefile index 8738d55..fad8b33 100644 --- renamed from Makefile +0 -0

@@ -124,7 +126,7 @@ $(obj)$(BOARD)-spl.bin: $(obj)u-boot-spl.bin 

endif

$(obj)u-boot-spl.bin: $(obj)u-boot-spl - $(OBJCOPY)
$(OBJCFLAGS) -O binary $< $@ + $(OBJCOPY) ${OBJCFLAGS}
--pad-to=$(PAD_TO) -O binary $< $@

GEN_UBOOT = \ UNDEF_SYM=`$(OBJDUMP) -x $(LIBS) | \

-----Original Message-----
From: Tom Rini [mailto:trini at ti.com]
Sent: Wednesday, September 19, 2012 6:29 PM
To: Jos? Miguel Gon?alves
Cc: Scott Wood; u-boot at lists.denx.de; marex at denx.de; mk7.kang at samsung.com; Tom Warren
Subject: Re: [PATCH v4 10/11] Add u-boot-pad.bin target to the Makefile

* PGP Signed by an unknown key

Quoted 95 lines · Jos? Miguel Gon?alves

Tom & Scott,

Quoted 48 lines · Tom Rini

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Quoted 45 lines · Scott Wood

Quoted 44 lines · Tom Rini

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Quoted 33 lines · Scott Wood

Quoted 17 lines · Jos? Miguel Gon?alves

Samsung's S3C24XX SoCs need this in order to generate a binary image with a padded SPL concatenated with U-Boot.

Signed-off-by Jos? Miguel Gon?alves <[email protected]> ---

Changes for v2: - None

Changes for v3: - Changed new binary target name from u-boot-ubl.bin to u-boot-pad.bin

Changes for v4: - None --- Makefile | 11 ++++++----- 1
file changed, 6 insertions(+), 5 deletions(-)

Makefile index 8738d55..86dedca renamed from Makefile +0 -0

100644 --- a/Makefile +++ b/Makefile @@ -433,14 +433,15
@@ $(obj)u-boot.sha1: $(obj)u-boot.bin
$(obj)u-boot.dis: $(obj)u-boot $(OBJDUMP) -d $< > $@

Quoted 12 lines

-$(obj)u-boot.ubl: $(obj)spl/u-boot-spl.bin
$(obj)u-boot.bin +$(obj)u-boot-pad.bin:
$(obj)spl/u-boot-spl.bin $(obj)u-boot.bin $(OBJCOPY) ${OBJCFLAGS} --pad-to=$(PAD_TO) -O binary $(obj)spl/u-boot-spl $(obj)spl/u-boot-spl-pad.bin - cat $(obj)spl/u-boot-spl-pad.bin $(obj)u-boot.bin >
$(obj)u-boot-ubl.bin - $(obj)tools/mkimage -n
$(UBL_CONFIG) -T ublimage \ - -e
$(CONFIG_SYS_TEXT_BASE) -d $(obj)u-boot-ubl.bin
$(obj)u-boot.ubl - rm $(obj)u-boot-ubl.bin + cat
$(obj)spl/u-boot-spl-pad.bin $(obj)u-boot.bin > $(obj)u-boot-pad.bin rm $(obj)spl/u-boot-spl-pad.bin

This rule lists u-boot-spl.bin as a prerequisite, but it doesn't appear to use it -- it uses u-boot-spl instead.

Quoted 5 lines

It seems that either spl/Makefile should produce u-boot-spl rather than u-boot-spl.bin and let the toplevel Makefile deal with converting it to a binary, or spl/Makefile should take care of adding any needed padding for the target and the final rule should just be a concatenation.

So, if we use a weak PAD_TO value of say 0x1, we could always "pad" u-boot-spl.bin out and then do the concatenation here and in a few other targets as well.

Quoted 7 lines

Quoted 2 lines

Yes, or use a variable that includes the linker option, so that it expands to an empty string if padding isn't required.

Yes, I don't know if say IMAGE_PAD ?= "" and having boards set that to - --pad-to=... or just saying --pad-to=$(PAD_SIZE) and PAD_SIZE ?= 0x1 ends up looking cleaner once all is said and done. First one to try both and patch... :)

Please check the following patch. It seems to work for me...

Makefile index 8738d55..fad8b33 100644 --- renamed from Makefile +0 -0

a/Makefile +++ b/Makefile @@ -433,13 +433,12 @@ $(obj)u-boot.sha1:
$(obj)u-boot.bin $(obj)u-boot.dis: $(obj)u-boot $(OBJDUMP) -d $<

Quoted 1 line

$@

-$(obj)u-boot.ubl: $(obj)spl/u-boot-spl.bin $(obj)u-boot.bin
- $(OBJCOPY) ${OBJCFLAGS} --pad-to=$(PAD_TO) -O binary
$(obj)spl/u-boot-spl $(obj)spl/u-boot-spl-pad.bin - cat
$(obj)spl/u-boot-spl-pad.bin $(obj)u-boot.bin > $(obj)u-boot-ubl.bin +$(obj)u-boot-with-spl.bin:
$(obj)spl/u-boot-spl.bin $(obj)u-boot.bin + cat $^ > $@ +
+$(obj)u-boot.ubl: $(obj)u-boot-with-spl.bin
$(obj)tools/mkimage -n $(UBL_CONFIG) -T ublimage \ - -e
$(CONFIG_SYS_TEXT_BASE) -d $(obj)u-boot-ubl.bin $(obj)u-boot.ubl -
rm $(obj)u-boot-ubl.bin - rm $(obj)spl/u-boot-spl-pad.bin +
-e $(CONFIG_SYS_TEXT_BASE) -d $< $@

$(obj)u-boot.ais: $(obj)spl/u-boot-spl.bin $(obj)u-boot.img
$(obj)tools/mkimage -s -n /dev/null -T aisimage \ diff --git a/spl/Makefile b/spl/Makefile index f96c08e..6ea9f26 100644 --- a/spl/Makefile +++ b/spl/Makefile @@ -23,6 +23,8 @@ include $(TOPDIR)/config.mk # We want the final binaries in this directory obj := $(OBJTREE)/spl/

+PAD_TO ?= 1 + HAVE_VENDOR_COMMON_LIB := $(shell [ -f $(SRCTREE)/board/$(VENDOR)/common/Makefile ] \ && echo y || echo
n)

Makefile index 8738d55..fad8b33 100644 --- renamed from Makefile +0 -1

@@ -124,7 +126,7 @@ $(obj)$(BOARD)-spl.bin: $(obj)u-boot-spl.bin endif
 
 $(obj)u-boot-spl.bin:    $(obj)u-boot-spl -    $(OBJCOPY)
 $(OBJCFLAGS) -O binary $< $@ +    $(OBJCOPY) ${OBJCFLAGS}
--pad-to=$(PAD_TO) -O binary $< $@
 

Makefile index 8738d55..fad8b33 100644 --- $(obj)$(BOARD)-spl.bin: $(obj)u-boot-spl.bin endif · line 130

Quoted 1 line

Makefile index 8738d55..fad8b33 100644 --- renamed from Makefile +0 -0

 GEN_UBOOT = \ UNDEF_SYM=`$(OBJDUMP) -x $(LIBS) | \

Tom W, since I'd like you to upgrade the tegra rules after this change goes in (since they do a u-boot-spl.bin + pad + u-boot.bin + stuff), does this look good to you as well? Thanks!

--
Tom

* Unknown Key
* 0x94391D56(L)

Quoted 116 lines

-----Original Message----- From: Tom Rini [mailto:trini at ti.com]
Sent: Wednesday, September 19, 2012 6:29 PM To: Jos? Miguel Gon?alves Cc: Scott Wood; u-boot at lists.denx.de; marex at denx.de; mk7.kang at samsung.com; Tom Warren Subject: Re: [PATCH v4 10/11] Add u-boot-pad.bin target to the Makefile

* PGP Signed by an unknown key

Quoted 107 lines · Jos? Miguel Gon?alves

Tom & Scott,

Quoted 54 lines · Tom Rini

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Quoted 51 lines · Scott Wood

Quoted 50 lines · Tom Rini

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Quoted 38 lines · Scott Wood

Quoted 20 lines · Jos? Miguel Gon?alves

Samsung's S3C24XX SoCs need this in order to
generate a binary image with a padded SPL
concatenated with U-Boot.

Signed-off-by: Jos? Miguel Gon?alves <[email protected]> --- Changes for v2: - None

Changes for v3: - Changed new binary target name from u-boot-ubl.bin to u-boot-pad.bin

Changes for v4: - None --- Makefile | 11
++++++----- 1 file changed, 6 insertions(+), 5
deletions(-)

Makefile index renamed from Makefile +0 -0

8738d55..86dedca 100644 --- a/Makefile +++ b/Makefile @@ -433,14 +433,15 @@ $(obj)u-boot.sha1:
$(obj)u-boot.bin $(obj)u-boot.dis: $(obj)u-boot $(OBJDUMP) -d $< > $@

Quoted 12 lines

-$(obj)u-boot.ubl: $(obj)spl/u-boot-spl.bin
$(obj)u-boot.bin +$(obj)u-boot-pad.bin:
$(obj)spl/u-boot-spl.bin $(obj)u-boot.bin $(OBJCOPY) ${OBJCFLAGS} --pad-to=$(PAD_TO) -O binary $(obj)spl/u-boot-spl $(obj)spl/u-boot-spl-pad.bin - cat $(obj)spl/u-boot-spl-pad.bin $(obj)u-boot.bin >
$(obj)u-boot-ubl.bin - $(obj)tools/mkimage -n
$(UBL_CONFIG) -T ublimage \ - -e
$(CONFIG_SYS_TEXT_BASE) -d $(obj)u-boot-ubl.bin
$(obj)u-boot.ubl - rm $(obj)u-boot-ubl.bin +
cat $(obj)spl/u-boot-spl-pad.bin $(obj)u-boot.bin > $(obj)u-boot-pad.bin rm $(obj)spl/u-boot-spl-pad.bin

This rule lists u-boot-spl.bin as a prerequisite, but it doesn't appear to use it -- it uses u-boot-spl instead.

Quoted 6 lines

It seems that either spl/Makefile should produce u-boot-spl rather than u-boot-spl.bin and let the toplevel Makefile deal with converting it to a binary, or spl/Makefile should take care of adding any needed padding for the target and the final rule should just be a concatenation.

So, if we use a weak PAD_TO value of say 0x1, we could always "pad" u-boot-spl.bin out and then do the concatenation here and in a few other targets as well.

Quoted 9 lines

Quoted 3 lines

Yes, or use a variable that includes the linker option, so that it expands to an empty string if padding isn't required.

Yes, I don't know if say IMAGE_PAD ?= "" and having boards set that to - --pad-to=... or just saying --pad-to=$(PAD_SIZE) and PAD_SIZE ?= 0x1 ends up looking cleaner once all is said and done. First one to try both and patch... :)

Please check the following patch. It seems to work for me...

Makefile index 8738d55..fad8b33 100644 renamed from Makefile +0 -1

--- a/Makefile +++ b/Makefile @@ -433,13 +433,12 @@ 

$(obj)u-boot.sha1: $(obj)u-boot.bin $(obj)u-boot.dis:
$(obj)u-boot $(OBJDUMP) -d $<

Quoted 1 line

$@

-$(obj)u-boot.ubl: $(obj)spl/u-boot-spl.bin
$(obj)u-boot.bin - $(OBJCOPY) ${OBJCFLAGS}
--pad-to=$(PAD_TO) -O binary $(obj)spl/u-boot-spl
$(obj)spl/u-boot-spl-pad.bin - cat
$(obj)spl/u-boot-spl-pad.bin $(obj)u-boot.bin > $(obj)u-boot-ubl.bin +$(obj)u-boot-with-spl.bin:
$(obj)spl/u-boot-spl.bin $(obj)u-boot.bin + cat $^ > $@
+ +$(obj)u-boot.ubl: $(obj)u-boot-with-spl.bin
$(obj)tools/mkimage -n $(UBL_CONFIG) -T ublimage \ - -e
$(CONFIG_SYS_TEXT_BASE) -d $(obj)u-boot-ubl.bin
$(obj)u-boot.ubl - rm $(obj)u-boot-ubl.bin - rm
$(obj)spl/u-boot-spl-pad.bin + -e $(CONFIG_SYS_TEXT_BASE) -d $< $@

$(obj)u-boot.ais: $(obj)spl/u-boot-spl.bin
$(obj)u-boot.img $(obj)tools/mkimage -s -n /dev/null -T aisimage \ diff --git a/spl/Makefile b/spl/Makefile index f96c08e..6ea9f26 100644 --- a/spl/Makefile +++ b/spl/Makefile

Makefile index 8738d55..fad8b33 100644 renamed from Makefile +0 -0

@@ -23,6 +23,8 @@ include $(TOPDIR)/config.mk # We want the 

final binaries in this directory obj := $(OBJTREE)/spl/

+PAD_TO ?= 1 + HAVE_VENDOR_COMMON_LIB := $(shell [ -f $(SRCTREE)/board/$(VENDOR)/common/Makefile ] \ && echo y || echo n)

Makefile index 8738d55..fad8b33 100644 renamed from Makefile +0 -0

@@ -124,7 +126,7 @@ $(obj)$(BOARD)-spl.bin: 

$(obj)u-boot-spl.bin endif

$(obj)u-boot-spl.bin: $(obj)u-boot-spl - $(OBJCOPY)
$(OBJCFLAGS) -O binary $< $@ + $(OBJCOPY) ${OBJCFLAGS}
--pad-to=$(PAD_TO) -O binary $< $@

Quoted 6 lines

Quoted 1 line

GEN_UBOOT = \ UNDEF_SYM=`$(OBJDUMP) -x $(LIBS) | \

Tom W, since I'd like you to upgrade the tegra rules after this change goes in (since they do a u-boot-spl.bin + pad + u-boot.bin + stuff), does this look good to you as well? Thanks!

I'm not clear what you want the final binary names to be. I seem to be missing segments of this discussion - maybe not CC'd on all threads?

-----Original Message-----
From: Tom Rini [mailto:trini at ti.com]
Sent: Thursday, September 20, 2012 9:23 AM
To: Tom Warren
Cc: Jos? Miguel Gon?alves; Scott Wood; u-boot at lists.denx.de; marex at denx.de; mk7.kang at samsung.com
Subject: Re: [PATCH v4 10/11] Add u-boot-pad.bin target to the Makefile

* PGP Signed by an unknown key

Quoted 116 lines · Tom Warren

Quoted 109 lines

-----Original Message----- From: Tom Rini [mailto:trini at ti.com]
Sent: Wednesday, September 19, 2012 6:29 PM To: Jos? Miguel Gon?alves
Cc: Scott Wood; u-boot at lists.denx.de; marex at denx.de; mk7.kang at samsung.com; Tom Warren Subject: Re: [PATCH v4 10/11] Add u-boot-pad.bin target to the Makefile

Quoted 1 line

Old Signed by an unknown key

Quoted 100 lines · Jos? Miguel Gon?alves

Tom & Scott,

Quoted 51 lines · Tom Rini

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Quoted 48 lines · Scott Wood

Quoted 47 lines · Tom Rini

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Quoted 36 lines · Scott Wood

Quoted 19 lines · Jos? Miguel Gon?alves

Samsung's S3C24XX SoCs need this in order to generate a binary image with a padded SPL concatenated with U-Boot.

Signed-off-by Jos? Miguel Gon?alves <[email protected]>

--- Changes for v2: - None

Changes for v3: - Changed new binary target name from u-boot-ubl.bin to u-boot-pad.bin

Changes for v4: - None --- Makefile | 11
++++++----- 1 file changed, 6 insertions(+), 5
deletions(-)

Makefile index 8738d55..86dedca 100644 renamed from Makefile +0 -1

--- a/Makefile +++ b/Makefile @@ -433,14 +433,15 @@

$(obj)u-boot.sha1:
$(obj)u-boot.bin $(obj)u-boot.dis: $(obj)u-boot
$(OBJDUMP) -d $< > $@

Quoted 12 lines

-$(obj)u-boot.ubl: $(obj)spl/u-boot-spl.bin
$(obj)u-boot.bin +$(obj)u-boot-pad.bin:
$(obj)spl/u-boot-spl.bin $(obj)u-boot.bin $(OBJCOPY) ${OBJCFLAGS} --pad-to=$(PAD_TO) -O binary $(obj)spl/u-boot-spl $(obj)spl/u-boot-spl-pad.bin - cat $(obj)spl/u-boot-spl-pad.bin $(obj)u-boot.bin >
$(obj)u-boot-ubl.bin - $(obj)tools/mkimage -n
$(UBL_CONFIG) -T ublimage \ - -e
$(CONFIG_SYS_TEXT_BASE) -d $(obj)u-boot-ubl.bin
$(obj)u-boot.ubl - rm $(obj)u-boot-ubl.bin +
cat $(obj)spl/u-boot-spl-pad.bin $(obj)u-boot.bin > $(obj)u-boot-pad.bin rm $(obj)spl/u-boot-spl-pad.bin

This rule lists u-boot-spl.bin as a prerequisite, but it doesn't appear to use it -- it uses u-boot-spl instead.

Quoted 5 lines

It seems that either spl/Makefile should produce u-boot-spl rather than u-boot-spl.bin and let the toplevel Makefile deal with converting it to a binary, or spl/Makefile should take care of adding any needed padding for the target and the final rule should just be a concatenation.

So, if we use a weak PAD_TO value of say 0x1, we could always "pad" u-boot-spl.bin out and then do the concatenation here and in a few other targets as well.

Quoted 7 lines

Quoted 2 lines

Yes, or use a variable that includes the linker option, so that it expands to an empty string if padding isn't required.

Yes, I don't know if say IMAGE_PAD ?= "" and having boards set that to - --pad-to=... or just saying
--pad-to=$(PAD_SIZE) and PAD_SIZE ?= 0x1 ends up looking cleaner once all is said and done. First one to try both and patch... :)

Please check the following patch. It seems to work for me...

Makefile index 8738d55..fad8b33 100644 renamed from Makefile +0 -1

--- a/Makefile +++ b/Makefile @@ -433,13 +433,12 @@

$(obj)u-boot.sha1: $(obj)u-boot.bin $(obj)u-boot.dis:
$(obj)u-boot $(OBJDUMP) -d $<

Quoted 1 line

$@

-$(obj)u-boot.ubl: $(obj)spl/u-boot-spl.bin
$(obj)u-boot.bin - $(OBJCOPY) ${OBJCFLAGS}
--pad-to=$(PAD_TO) -O binary $(obj)spl/u-boot-spl
$(obj)spl/u-boot-spl-pad.bin - cat
$(obj)spl/u-boot-spl-pad.bin $(obj)u-boot.bin > $(obj)u-boot-ubl.bin +$(obj)u-boot-with-spl.bin:
$(obj)spl/u-boot-spl.bin $(obj)u-boot.bin + cat $^ > $@
+ +$(obj)u-boot.ubl: $(obj)u-boot-with-spl.bin
$(obj)tools/mkimage -n $(UBL_CONFIG) -T ublimage \ - -e
$(CONFIG_SYS_TEXT_BASE) -d $(obj)u-boot-ubl.bin
$(obj)u-boot.ubl - rm $(obj)u-boot-ubl.bin - rm
$(obj)spl/u-boot-spl-pad.bin + -e $(CONFIG_SYS_TEXT_BASE) -d $< $@

$(obj)u-boot.ais: $(obj)spl/u-boot-spl.bin
$(obj)u-boot.img $(obj)tools/mkimage -s -n /dev/null -T aisimage \

spl/Makefile index renamed from spl/Makefile +0 -0

f96c08e..6ea9f26 100644 --- a/spl/Makefile +++ b/spl/Makefile @@ -23,6 +23,8 @@ include $(TOPDIR)/config.mk # We want the final binaries in this directory obj := $(OBJTREE)/spl/

+PAD_TO ?= 1 + HAVE_VENDOR_COMMON_LIB := $(shell [ -f $(SRCTREE)/board/$(VENDOR)/common/Makefile ] \ && echo y || echo n)

spl/Makefile index renamed from spl/Makefile +0 -0

@@ -124,7 +126,7 @@ $(obj)$(BOARD)-spl.bin:

$(obj)u-boot-spl.bin endif

$(obj)u-boot-spl.bin: $(obj)u-boot-spl - $(OBJCOPY)
$(OBJCFLAGS) -O binary $< $@ + $(OBJCOPY) ${OBJCFLAGS}
--pad-to=$(PAD_TO) -O binary $< $@

Quoted 6 lines

Quoted 1 line

GEN_UBOOT = \ UNDEF_SYM=`$(OBJDUMP) -x $(LIBS) | \

Tom W, since I'd like you to upgrade the tegra rules after this change goes in (since they do a u-boot-spl.bin + pad + u-boot.bin + stuff), does this look good to you as well?
Thanks!

Quoted 2 lines

I'm not clear what you want the final binary names to be. I seem to be missing segments of this discussion - maybe not CC'd on all threads?

Sorry, I'm just asking if this way of padding u-boot-spl.bin to the required size by default in spl/Makefile and then not doing any --pad-to in the toplevel Makefile rules for u-boot-spl will work for your needs as well (so update the existing rules to just concatenate spl/u-boot-spl.bin and u- boot.bin and whatever else you need and have PAD_TO be set to $(CONFIG_SYS_TEXT_BASE), I believe).

--
Tom

* Unknown Key
* 0x94391D56(L)

Quoted 5 lines

-----Original Message-----
From: Tom Rini [mailto:trini at ti.com]
Sent: Wednesday, September 19, 2012 6:29 PM
To: Jos? Miguel Gon?alves
Cc: Scott Wood; u-boot at lists.denx.de; marex at denx.de;

mk7.kang at samsung.com;

Quoted 2 lines

Tom Warren
Subject: Re: [PATCH v4 10/11] Add u-boot-pad.bin target to the

Makefile

Quoted 2 lines

Tom W, since I'd like you to upgrade the tegra rules after this

change goes

Quoted 1 line

in (since they do a u-boot-spl.bin + pad + u-boot.bin + stuff),

does this

Quoted 1 line

look good to you as well? Thanks!

I'm not clear what you want the final binary names to be. I seem to be missing segments of this discussion - maybe not CC'd on all threads?

With Tegra, if you flash u-boot.bin, you'll get a DT-less, non-functional binary that will print a 'DT missing!' message and reset ad infinitum. Most folks won't see or care about u-boot-spl.bin, since it's hidden in the spl/ subdir. I don't see the use of having a 'u-boot-with-spl.bin' - doesn't u-boot-spl.bin say the same thing?

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.

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.

Quoted 12 lines · Tom Warren

Quoted 11 lines

-----Original Message-----
From: Tom Rini [mailto:trini at ti.com]
Sent: Wednesday, September 19, 2012 6:29 PM
To: Jos? Miguel Gon?alves
Cc: Scott Wood; u-boot at lists.denx.de; marex at denx.de; mk7.kang at samsung.com; Tom Warren
Subject: Re: [PATCH v4 10/11] Add u-boot-pad.bin target to the Makefile

Tom W, since I'd like you to upgrade the tegra rules after this change goes in (since they do a u-boot-spl.bin + pad + u-boot.bin + stuff), does this look good to you as well? Thanks!

Quoted 8 lines

I'm not clear what you want the final binary names to be. I seem to be missing segments of this discussion - maybe not CC'd on all threads?

With Tegra, if you flash u-boot.bin, you'll get a DT-less, non-functional binary that will print a 'DT missing!' message and reset ad infinitum. Most folks won't see or care about u-boot-spl.bin, since it's hidden in the spl/ subdir. I don't see the use of having a 'u-boot-with-spl.bin' - doesn't u-boot-spl.bin say the same thing?

u-boot-spl.bin is just the SPL. u-boot-with-spl.bin is SPL plus u-boot.

Or maybe the former could just become spl.bin, and then u-boot-spl.bin could mean the latter? There's really no reason to put "u-boot" in the name of every intermediate file that represents something more specific.

Quoted 4 lines

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.

It's useful to leave intermediate files around for debugging.

Quoted 2 lines

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.

If the only thing Tegra-specific about the output format is that it has a dtb bundled, I think it should have a more generic name, as other targets could end up using a dtb as well.

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.

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

Dear Tom,

Quoted 4 lines · In message <[email protected]>…

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.

Quoted 3 lines

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.

Quoted 4 lines

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?

Dear Jos? Miguel Gon?alves,

Quoted 8 lines · In message <[email protected]> you wrote:

Quoted 3 lines

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.

Quoted 4 lines

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?

SoC specific make rules can probably be added to the respective SoC specific makefiles, thus still avoiding to clutter the top level Makefile with lots of conditionals.

Best regards,

Wolfgang Denk

Dear Jos? Miguel Gon?alves,

Quoted 10 lines · In message <[email protected]> you wrote:

Quoted 5 lines

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.

Quoted 4 lines

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?

SoC specific make rules can probably be added to the respective SoC specific makefiles, thus still avoiding to clutter the top level Makefile with lots of conditionals.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Quoted 11 lines · Wolfgang Denk

Dear Jos? Miguel Gon?alves,

Quoted 8 lines · In message <[email protected]> you wrote:

Quoted 4 lines

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.

Quoted 7 lines

Quoted 4 lines

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?

SoC specific make rules can probably be added to the respective SoC specific makefiles, thus still avoiding to clutter the top level Makefile with lots of conditionals.

Ideally? Yes, Possible today? Not sure. I have a hazy recollection that it wasn't so easy when I tried adding some build rules to one of the config.mk files. When I post SPI SPL for am335x support I'll try again since for that I need to add a rule to generate a byte-swapped MLO file. If that can go somewhere other than spl/Makefile that would be nice (but needs to be visible to a number of TI SoCs is an issue).

Quoted 22 lines · Tom Rini

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Quoted 12 lines · Wolfgang Denk

Dear Jos? Miguel Gon?alves,

Quoted 9 lines · In message <[email protected]> you wrote:

Quoted 4 lines

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.

Quoted 7 lines

Quoted 4 lines

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?

SoC specific make rules can probably be added to the respective SoC specific makefiles, thus still avoiding to clutter the top level Makefile with lots of conditionals.

Quoted 8 lines

Ideally? Yes, Possible today? Not sure. I have a hazy recollection that it wasn't so easy when I tried adding some build rules to one of the config.mk files. When I post SPI SPL for am335x support I'll try again since for that I need to add a rule to generate a byte-swapped MLO file. If that can go somewhere other than spl/Makefile that would be nice (but needs to be visible to a number of TI SoCs is an issue).

So what is your suggestion for my patch? Can I push it with a new "u-boot-with-spl.bin" target and you'll handle the unification of all NAND targets later?

Quoted 3 lines

SoC specific make rules can probably be added to the respective SoC specific makefiles, thus still avoiding to clutter the top level Makefile with lots of conditionals.

Ideally? Yes, Possible today? Not sure. I have a hazy recollection that it wasn't so easy when I tried adding some build rules to one of the config.mk files. When I post SPI SPL for am335x support I'll try again since for that I need to add a rule to generate a byte-swapped MLO file. If that can go somewhere other than spl/Makefile that would be nice (but needs to be visible to a number of TI SoCs is an issue).

- --
Tom

Dear Tom,

In message <[email protected]> you

Quoted 5 lines · 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.

Quoted 2 lines

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

Quoted 1 line

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.

Quoted 52 lines

Dear Tom,

In message <[email protected]> you

Quoted 4 lines · 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.

Quoted 2 lines

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

Quoted 1 line

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"]

Quoted 5 lines

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.

The awkwardness with naming based on nand/onenand/sd is that we no longer have build infrastructure that is specific to the type of boot device -- and IIRC with some of the newer SPL targets, the same image works on multiple types of boot device.

Having u-boot.bin be the final output regardless of internal implementation details such as spl would avoid that problem, and be even nicer to automated testing than the nand/onenand/sd names.

-Scott

Dear Scott Wood,

Quoted 2 lines

The awkwardness with naming based on nand/onenand/sd is that we no longer have build infrastructure that is specific to the type of

boot

Quoted 1 line

device -- and IIRC with some of the newer SPL targets, the same

image

Quoted 2 lines

works on multiple types of boot device.

Quoted 3 lines

Having u-boot.bin be the final output regardless of internal implementation details such as spl would avoid that problem, and be even nicer to automated testing than the nand/onenand/sd names.

On the other hand, I use u-boot.bin and expect it to always be the raw linked
binary of u-boot .

Quoted 13 lines

Dear Scott Wood,

Quoted 2 lines

The awkwardness with naming based on nand/onenand/sd is that we no longer have build infrastructure that is specific to the type of

boot

Quoted 1 line

device -- and IIRC with some of the newer SPL targets, the same

image

Quoted 2 lines

works on multiple types of boot device.

Quoted 7 lines

Quoted 3 lines

Having u-boot.bin be the final output regardless of internal implementation details such as spl would avoid that problem, and be even nicer to automated testing than the nand/onenand/sd names.

On the other hand, I use u-boot.bin and expect it to always be the raw linked
binary of u-boot .

What is U-Boot? Is it the thing that SPL loads, or is it the entire package that pops out when I tell the U-Boot makefiles to build something?

Of course the raw binary of the thing that SPL loads would still be available under some new name. Or come up with a new name for the final output, but I think the number of people that care about the final output is larger than the number of people that care about the raw binary of the thing that SPL loads.

As I said earlier, this is a situation where you can't please everyone, and I think it's better to have the current state of things be sane than to preserve one historical meaning of a particular target name rather than the other (originally there was no SPL and u-boot.bin was both the linker output and the final image to put into flash -- and this is still the case for many/most boards).

-Scott

Dear Scott Wood,

Quoted 4 lines · Marek Vasut

Quoted 3 lines

Dear Scott Wood,

Quoted 1 line

The awkwardness with naming based on nand/onenand/sd is that we

no

Quoted 4 lines

Quoted 4 lines

Quoted 1 line

longer have build infrastructure that is specific to the type of

boot

Quoted 8 lines

Quoted 8 lines

Quoted 1 line

device -- and IIRC with some of the newer SPL targets, the same

image

Quoted 4 lines

works on multiple types of boot device.

Having u-boot.bin be the final output regardless of internal implementation details such as spl would avoid that problem,

and be

Quoted 10 lines

Quoted 5 lines

Quoted 1 line

even nicer to automated testing than the nand/onenand/sd names.

On the other hand, I use u-boot.bin and expect it to always be the raw linked
binary of u-boot .

What is U-Boot? Is it the thing that SPL loads, or is it the entire package that pops out when I tell the U-Boot makefiles to build something?

Quoted 7 lines

Of course the raw binary of the thing that SPL loads would still be available under some new name. Or come up with a new name for the final output, but I think the number of people that care about the final output is larger than the number of people that care about the raw binary of the thing that SPL loads.

As I said earlier, this is a situation where you can't please

everyone,

Quoted 3 lines

and I think it's better to have the current state of things be sane than to preserve one historical meaning of a particular target name rather than the other (originally there was no SPL and u-boot.bin

was

Quoted 2 lines

both the linker output and the final image to put into flash -- and this is still the case for many/most boards).

Leave u-boot.bin be, that's the u-boot binary ...

the new name might be u-boot.img (as in flash image), what do you say ?

Leave u-boot.bin be, that's the u-boot binary ... the new name might be u- boot.img (as in flash image), what do you say ?

The MINI2416 board is based on a Samsung's S3C2416 SoC and has 64MB DDR2 SDRAM, 256MB NAND Flash, a LAN9220 Ethernet Controller and a WM8731 Audio CODEC. This U-Boot port was implemented and tested on a unit bought to Boardcon
(http://www.armdesigner.com/) but there are some other chinese providers that can supply it with a selectable NAND chip from 128MB to 1GB.

Signed-off-by Jos?? Miguel Gon??alves <[email protected]>

---
Changes for v2:
- Coding style cleanup

+#define CONFIG_SYS_BAUDRATE_TABLE { 9600, 19200, 38400, 57600, 115200 }

Quoted 6 lines · Jos?? Miguel Gon??alves

The MINI2416 board is based on a Samsung's S3C2416 SoC and has 64MB DDR2 SDRAM, 256MB NAND Flash, a LAN9220 Ethernet Controller and a WM8731 Audio CODEC. This U-Boot port was implemented and tested on a unit bought to Boardcon
(http://www.armdesigner.com/) but there are some other chinese providers that can supply it with a selectable NAND chip from 128MB to 1GB.

Quoted 4 lines

Signed-off-by Jos?? Miguel Gon??alves <[email protected]>

---
Changes for v2:
- Coding style cleanup

There's still at least one #define[tab]NAME in the code, please checkpatch.pl the whole series.

Quoted 2 lines

+#define CONFIG_SYS_BAUDRATE_TABLE { 9600, 19200, 38400, 57600, 115200 }

This is in the defaults now, please remove.