BOOT: Add "bootz" command to boot Linux zImage

This command boots Linux zImage from where the zImage is loaded to. Passing initrd and fdt is supported.

common/cmd_bootm.c +0 -1

@@ -160,35 +160,8 @@ static boot_os_fn *boot_os[] = {
 
 bootm_headers_t images;		/* pointers to os/initrd/fdt images */
 
-/* Allow for arch specific config before we boot */

common/image.c +14 -0

+#ifdef	CONFIG_LMB
+void boot_start_lmb(bootm_headers_t *images)
+{
+	ulong		mem_start;
+	phys_size_t	mem_size;
+
+	lmb_init(&images->lmb);
+
+	mem_start = getenv_bootm_low();
+	mem_size = getenv_bootm_size();
+
+	lmb_add(&images->lmb, (phys_addr_t)mem_start, mem_size);
+
+	arch_lmb_reserve(&images->lmb);

include/image.h +0 -0

index bbf80f0..26b8a20 100644

Dear Marek Vasut,

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

This command boots Linux zImage from where the zImage is loaded to. Passing initrd and fdt is supported.

I have but a few formal questions / issues.

...

Quoted 16 lines

common/cmd_bootm.c +0 -6

@@ -160,35 +160,8 @@ static boot_os_fn *boot_os[] = {
 
 bootm_headers_t images;		/* pointers to os/initrd/fdt images */
 
-/* Allow for arch specific config before we boot */
-void __arch_preboot_os(void)
-{
-	/* please define platform specific arch_preboot_os() */
-}
-void arch_preboot_os(void) __attribute__((weak,

alias("__arch_preboot_os"))); -

#define IH_INITRD_ARCH IH_ARCH_DEFAULT

common/cmd_bootm.c static boot_os_fn *boot_os[] = { · line 173

Quoted 2 lines

common/cmd_bootm.c +0 -2

-static void bootm_start_lmb(void)
-{

...

Note: this is bootm (or boot*) related code.

common/image.c static int fit_check_ramdisk(const void *fit, int · line 3190

Quoted 4 lines

common/image.c +0 -0

@@ -3190,3 +3190,28 @@ static int fit_check_ramdisk(const void *fit, int
 rd_noffset, uint8_t arch,

This is a file that deals with U-Boot images etc. It is in no way related to any of the "boot*" commands.

Quoted 15 lines

common/image.c +15 -0

+#ifdef	CONFIG_LMB
+void boot_start_lmb(bootm_headers_t *images)
+{
+	ulong		mem_start;
+	phys_size_t	mem_size;
+
+	lmb_init(&images->lmb);
+
+	mem_start = getenv_bootm_low();
+	mem_size = getenv_bootm_size();
+
+	lmb_add(&images->lmb, (phys_addr_t)mem_start, mem_size);
+
+	arch_lmb_reserve(&images->lmb);
+	board_lmb_reserve(&images->lmb);

common/image.c static int fit_check_ramdisk(const void *fit, int rd_noffset, uint8_t arch,

Quoted 10 lines

common/image.c +9 -0

+}
+#endif
+
+/* Allow for arch specific config before we boot */
+void __arch_preboot_os(void)
+{
+	/* please define platform specific arch_preboot_os() */
+}
+void arch_preboot_os(void) __attribute__((weak,
 alias("__arch_preboot_os")));

Putting this code here makes no sense. You could chose any othewr random file as well.

Quoted 6 lines

include/image.h +0 -0

index bbf80f0..26b8a20 100644
@@ -486,6 +486,14 @@ void image_multi_getimg(const image_header_t *hdr,
 ulong idx,

include/image.h void image_multi_getimg(const image_header_t *hdr, · line 496

Quoted 10 lines

include/image.h +7 -0

 
 void image_print_contents(const void *hdr);
 
+#ifdef CONFIG_LMB
+void boot_start_lmb(bootm_headers_t *images);
+#else
+static inline void boot_start_lmb(bootm_headers_t *image) { }
+#endif
+
+extern void arch_preboot_os(void);

Sorry, no. image.[ch] is definitely not the right place for this stuff.

Best regards,

Wolfgang Denk

Quoted 2 lines

I have but a few formal questions / issues.

I had a dilemma about the image.[ch] indeed. I was quite unsure where to put those, can you suggest proper location? I didn't want to create new file only for that matter.

Dear Marek Vasut,

btw - there is no need to full-quote.

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

Quoted 1 line

I have but a few formal questions / issues.

I had a dilemma about the image.[ch] indeed. I was quite unsure where to put those, can you suggest proper location? I didn't want to create new file only for that matter.

Sorry, I have no good idea either.

If you omit comment header and includes, common/cmd_bootz.c adds less than 10% to common/cmd_bootm.c - unless we extrace more common code from other boot* commands, you might even add it to cmd_bootm.c (with #ifdef's).

While we are at it:

Do we have to care about endianess here?

Best regards,

Wolfgang Denk

Dear Wolfgang Denk,

Quoted 6 lines

While we are at it:

+ ? ? zi = (struct zimage_header *)images->ep; +
+ ? ? if (zi->zi_magic != LINUX_ARM_ZIMAGE_MAGIC) {

This gave me an idea ... this might be how to check for zImage inside bootm and be done with it. Simply squash those two together.

While we are on the subject - Do either of you think support for the x86 zimage/bzImage format should end up here in common code? Not that the x86

(b)zImage header is unique (see arch/x86/include/asm/bootparam.h) and decompressing vmlinux out of an x86 (b)zImage is non-trivial given the header and decompression stub

Dear Graeme Russ,

Quoted 3 lines · In message <CALButCLDyKZnsZqGXhxcu-UEv9nySg77f1XwaUvmgb9gc7BPNQ@mail.gmail.com>…

While we are on the subject - Do either of you think support for the x86 zimage/bzImage format should end up here in common code? Not that the x86

The common coe should be architecture-neutral. ?It might cann architecture-specific routines, which may (or may not) get added later, depending if somebody cares about adding such support.

Quoted 3 lines

(b)zImage header is unique (see arch/x86/include/asm/bootparam.h) and decompressing vmlinux out of an x86 (b)zImage is non-trivial given the header and decompression stub

I have to admit that I never understood the fuzz about being able to boot zImages. ?I see more disadvanatges than advantages for this, but

some ARM people go frenzy when this topic pops up - see recent discussions about removal of uImage support on the AKML.

Frankly: I see no benefit in adding x86 support.

I see no benefit in adding ARM support either, but YMMV...

Quoted 2 lines

Frankly: I see no benefit in adding x86 support.

Ouch! - Do you mean in common code or in general?

Quoted 1 line

I see no benefit in adding ARM support either, but YMMV...

Hmm, methinks the Android guys might have a bone to pick with that statement ;)

Dear Graeme Russ,

In message

Quoted 3 lines

Quoted 1 line

Frankly: I see no benefit in adding x86 support.

Ouch! - Do you mean in common code or in general?

I mean: I see no benefit in adding support for a "bootz" command for x86 systems - and I don't see it on Power Architecture either.

Quoted 5 lines

Quoted 2 lines

I see no benefit in adding ARM support either, but YMMV...

Hmm, methinks the Android guys might have a bone to pick with that statement ;)

Andoid? What or who is that? ;-)

Best regards,

Wolfgang Denk

Dear Graeme Russ,

In message <CALButCLDyKZnsZqGXhxcu-

Quoted 2 lines

While we are on the subject - Do either of you think support for the x86 zimage/bzImage format should end up here in common code? Not that the x86

The common coe should be architecture-neutral. It might cann architecture-specific routines, which may (or may not) get added later, depending if somebody cares about adding such support.

Quoted 3 lines

(b)zImage header is unique (see arch/x86/include/asm/bootparam.h) and decompressing vmlinux out of an x86 (b)zImage is non-trivial given the header and decompression stub

I have to admit that I never understood the fuzz about being able to boot zImages. I see more disadvanatges than advantages for this, but some ARM people go frenzy when this topic pops up - see recent discussions about removal of uImage support on the AKML.

Frankly: I see no benefit in adding x86 support.

I see no benefit in adding ARM support either, but YMMV...

Best regards,

Wolfgang Denk

Quoted 5 lines

I have to admit that I never understood the fuzz about being able to boot zImages. I see more disadvanatges than advantages for this, but some ARM people go frenzy when this topic pops up - see recent discussions about removal of uImage support on the AKML.

Sure, but let's try to offer them a compromise. Everyone will be happy that way at least to some extent.

Dear Marek Vasut,

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

Quoted 4 lines

I have to admit that I never understood the fuzz about being able to boot zImages. I see more disadvanatges than advantages for this, but some ARM people go frenzy when this topic pops up - see recent discussions about removal of uImage support on the AKML.

Quoted 2 lines

Sure, but let's try to offer them a compromise. Everyone will be happy that way at least to some extent.

I have nothing against compromizes. But are you soure about the "everyone" in the second sentence? I think we know a few guys who mightnot.

And actually it might backfire as well - I see JC argumenting: now they (finally!) support the one true image format, no let's throw out their stupid uImage support, nobody needs this any more.

Just like nobody needs to be able to use a ramdisk image from NOR flash without loading it to RAM before, etc.

Best regards,

Wolfgang Denk

common/cmd_bootz.c line 90

Quoted 4 lines

common/cmd_bootz.c new file +3 -0

+	zi = (struct zimage_header *)images->ep;
+
+	if (zi->zi_magic != LINUX_ARM_ZIMAGE_MAGIC) {

This gave me an idea ... this might be how to check for zImage inside bootm and be done with it. Simply squash those two together.

Quoted 1 line

Do we have to care about endianess here?

We should make bootz arm-specific until more people (with different arches) step up and verify it works for them.

Dear Marek Vasut,

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

common/cmd_bootz.c line 90

Quoted 3 lines

common/cmd_bootz.c new file +3 -0

+	zi = (struct zimage_header *)images->ep;
+
+	if (zi->zi_magic != LINUX_ARM_ZIMAGE_MAGIC) {

This gave me an idea ... this might be how to check for zImage inside bootm and be done with it. Simply squash those two together.

Hm... but this must not be the only test, then, or you will run the risk of false positives...

Quoted 5 lines

Quoted 2 lines

Do we have to care about endianess here?

We should make bootz arm-specific until more people (with different arches) step up and verify it works for them.

NAK. Please implement in an architecture independent way right from the beginning.

Best regards,

Wolfgang Denk

Dear Wolfgang Denk,

Quoted 7 lines

Dear Marek Vasut,

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

Quoted 3 lines

+ zi = (struct zimage_header *)images->ep;
+
+ if (zi->zi_magic != LINUX_ARM_ZIMAGE_MAGIC) {

Quoted 5 lines

Quoted 2 lines

This gave me an idea ... this might be how to check for zImage inside bootm and be done with it. Simply squash those two together.

Hm... but this must not be the only test, then, or you will run the risk of false positives...

Certainly.

Quoted 3 lines

Quoted 3 lines

Quoted 2 lines

Do we have to care about endianess here?

Quoted 5 lines

Quoted 2 lines

We should make bootz arm-specific until more people (with different arches) step up and verify it works for them.

NAK. ?Please implement in an architecture independent way right from the beginning.

Can someone tell if the the zImage format differs per-arch or is it the same? Graeme, what is it about that x86 stuff?

 common/Makefile    |    1 +
 common/cmd_bootm.c |   29 +--------
 common/cmd_bootz.c |  175
 include/image.h    |    8 +++

+#define IH_INITRD_ARCH IH_ARCH_DEFAULT

+void __arch_preboot_os(void)

 arch/arm/lib/bootm.c     |   30 ++++++++++
 common/cmd_bootm.c       |  141

include/config_cmd_all.h |

+int do_bootz(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])

Quoted 3 lines

 arch/arm/lib/bootm.c     |   30 ++++++++++
 common/cmd_bootm.c       |  141

include/config_cmd_all.h |

still missing README

arch/arm/lib/bootm.c

Quoted 5 lines

arch/arm/lib/bootm.c +1 -0

 
+#ifdef	CONFIG_CMD_BOOTZ

don't use tabs to indent these tokens

Quoted 3 lines

common/cmd_bootm.c +0 -0

Quoted 1 line

+int __bootz_setup(void *image, void **start, void **end)

static

Quoted 1 line

+int do_bootz(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])

static
-mike

Quoted 6 lines · On Tuesday 13 March 2012 21:38:13 Marek Vasut wrote:

Quoted 3 lines

 arch/arm/lib/bootm.c     |   30 ++++++++++
 common/cmd_bootm.c       |  141

include/config_cmd_all.h |

still missing README

Where exactly would you squash it in there?

This command boots Linux zImage from where the zImage is loaded to. Passing initrd and fdt is supported.

+int do_bootz(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])

Quoted 2 lines

This command boots Linux zImage from where the zImage is loaded to. Passing initrd and fdt is supported.

i've got no opinion on the matter of supporting zImage directly (although, i guess it'd be nice since some legacy platforms still use it like netwinders)

Quoted 2 lines

+int do_bootz(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])

static

-mike

Quoted 7 lines · On Tuesday 13 March 2012 23:47:56 Marek Vasut wrote:

Quoted 2 lines

This command boots Linux zImage from where the zImage is loaded to. Passing initrd and fdt is supported.

i've got no opinion on the matter of supporting zImage directly (although, i guess it'd be nice since some legacy platforms still use it like netwinders)

Does anyone else but RMK have a working netwinder these days? >:-)

Quoted 4 lines

Quoted 2 lines

+int do_bootz(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])

static

NAK, compiler won't chew that

Quoted 4 lines

Quoted 4 lines · On Tuesday 13 March 2012 23:47:56 Marek Vasut wrote:

Quoted 2 lines

This command boots Linux zImage from where the zImage is loaded to. Passing initrd and fdt is supported.

Quoted 5 lines

Quoted 3 lines

i've got no opinion on the matter of supporting zImage directly (although, i guess it'd be nice since some legacy platforms still use it like netwinders)

Does anyone else but RMK have a working netwinder these days? >:-)

i've got 3, but only one is actively running

Quoted 4 lines

Quoted 4 lines

Quoted 3 lines

+int do_bootz(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])

Quoted 3 lines

Quoted 1 line

static

NAK, compiler won't chew that

what are you talking about ? you need to provide real details when making statements like this. plenty of other cmd's in u-boot mark their do_xxx func static and they work just fine. this do_bootz isn't used externally, so it makes no sense to have it be public.

-mike

Quoted 4 lines

i've got no opinion on the matter of supporting zImage directly (although, i guess it'd be nice since some legacy platforms still use it like netwinders)

Does anyone else but RMK have a working netwinder these days? >:-)

Dear Marek Vasut,

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

Quoted 3 lines

i've got no opinion on the matter of supporting zImage directly (although, i guess it'd be nice since some legacy platforms still use it like netwinders)

Does anyone else but RMK have a working netwinder these days? >:-)

And I bet a crate of beer that _him_ is not using U-Boot to boot it.

Best regards,

Wolfgang Denk

Quoted 5 lines · Marek Vasut

Quoted 3 lines

i've got no opinion on the matter of supporting zImage directly (although, i guess it'd be nice since some legacy platforms still use it like netwinders)

Does anyone else but RMK have a working netwinder these days? >:-)

And I bet a crate of beer that _him_ is not using U-Boot to boot it.

Quoted 5 lines

Quoted 4 lines · Marek Vasut

Quoted 3 lines

i've got no opinion on the matter of supporting zImage directly (although, i guess it'd be nice since some legacy platforms still use it like netwinders)

Quoted 3 lines

Quoted 1 line

Does anyone else but RMK have a working netwinder these days? >:-)

And I bet a crate of beer that _him_ is not using U-Boot to boot it.

i'm still using nettrom on my netwinder. the main guy (Ralph) has the source to it iirc, but wasn't able to release it. a u-boot port at this point wouldn't work without those board details :(.

From: Marek Vasut <[email protected]>

This command boots Linux zImage from where the zImage is loaded to. Passing initrd and fdt is supported.

Tested on i.MX28 based DENX M28EVK
Tested on PXA270 based Voipac PXA270.

NOTE: This currently only supports ARM, but other architectures can be easily added by defining bootz_setup().

Signed-off-by Marek Vasut <[email protected]>

Quoted 5 lines

From: Marek Vasut <[email protected]>

This command boots Linux zImage from where the zImage is loaded to. Passing initrd and fdt is supported.

Quoted 7 lines

Tested on i.MX28 based DENX M28EVK
Tested on PXA270 based Voipac PXA270.

NOTE: This currently only supports ARM, but other architectures can be easily added by defining bootz_setup().

Signed-off-by Marek Vasut <[email protected]>

On Tegra20 Harmony with and without device tree (against mainline) and Tegra30 Cardhu with device tree (against an NVIDIA-internal U-Boot tree),

Tested-by Stephen Warren <[email protected]>

The code looks good too; I believe you've take care of any comments I had on the first very you posted.

Thanks very much - this is awesome!

From: Marek Vasut <[email protected]>

This command boots Linux zImage from where the zImage is loaded to. Passing initrd and fdt is supported.

Tested on i.MX28 based DENX M28EVK
Tested on PXA270 based Voipac PXA270.

NOTE: This currently only supports ARM, but other architectures can be easily added by defining bootz_setup().

Signed-off-by Marek Vasut <[email protected]>

Cc Tom Warren <[email protected]>

Cc albert.u.boot at aribaud.net

Cc afleming at gmail.com,

Cc Simon Glass <[email protected]>,

Cc Stephen Warren <[email protected]>

Cc Nicolas Pitre <[email protected]>

Cc Wolfgang Denk <[email protected]>

Cc Detlev Zundel <[email protected]>

---
 README                   |    8 +++
 arch/arm/lib/bootm.c     |   30 ++++++++++
 common/cmd_bootm.c       |  141 +++++++++++++++++++++++++++++++++++++++++++---
 include/config_cmd_all.h |    1 +
 4 files changed, 171 insertions(+), 9 deletions(-)

V2: Use CONFIG_BOOTZ_MAX_KERNEL_LMB_SIZE to reserve kernel LMB
V3: Compute the LMB size at runtime (obsoletes V2)
Move shared code to image.c/image.h
Sync with latest U-Boot
V4: Add all this into cmd_bootm. Therefore, this is part of cmd_bootm (basically
it's stripped-down version). Also, separate out arm-specific component into arm-specific location.
V5: Staticize bootz_setup(), add information into README.
V6: Make cmd_bootz() static.

README +8 -0

index 4021715..b273070 100644
@@ -3594,6 +3594,7 @@ go	- start application at address 'addr'
 run	- run commands in an environment variable
 bootm	- boot application image from memory
 bootp	- boot image via network using BootP/TFTP protocol
+bootz   - boot zImage from memory
 tftpboot- boot image via network using TFTP protocol
 	       and env variables "ipaddr" and "serverip"
 	       (and eventually "gatewayip")

@@ -4414,6 +4415,13 @@ U-Boot supports the following image types:
 	useful when you configure U-Boot to use a real shell (hush)
 	as command interpreter.
 
+Booting the Linux zImage:
+-------------------------
+
+On some platforms, it's possible to boot Linux zImage. This is done
+using the "bootz" command. The syntax of "bootz" command is the same
+as the syntax of "bootm" command.
+
 
 Standalone HOWTO:
 =================

arch/arm/lib/bootm.c +30 -0

index afa0093..ec46d76 100644
@@ -344,3 +344,33 @@ static ulong get_sp(void)
 	asm("mov %0, sp" : "=r"(ret) : );
 	return ret;
 }
+
+#ifdef CONFIG_CMD_BOOTZ
+
+struct zimage_header {
+	uint32_t	code[9];
+	uint32_t	zi_magic;
+	uint32_t	zi_start;
+	uint32_t	zi_end;
+};
+
+#define	LINUX_ARM_ZIMAGE_MAGIC	0x016f2818
+
+int bootz_setup(void *image, void **start, void **end)
+{
+	struct zimage_header *zi = (struct zimage_header *)image;
+
+	if (zi->zi_magic != LINUX_ARM_ZIMAGE_MAGIC) {
+		puts("Bad Linux ARM zImage magic!\n");
+		return 1;
+	}
+
+	*start = (void *)zi->zi_start;
+	*end = (void *)zi->zi_end;
+
+	debug("Kernel image @ 0x%08x [ 0x%08x - 0x%08x ]\n",
+		(uint32_t)image, (uint32_t)*start, (uint32_t)*end);
+
+	return 0;
+}
+#endif	/* CONFIG_CMD_BOOTZ */

common/cmd_bootm.c +132 -9

index d5745b1..b49d4f7 100644
@@ -169,25 +169,25 @@ void arch_preboot_os(void) __attribute__((weak, alias("__arch_preboot_os")));
 
 #define IH_INITRD_ARCH IH_ARCH_DEFAULT
 
-static void bootm_start_lmb(void)
-{
 #ifdef CONFIG_LMB
+static void boot_start_lmb(bootm_headers_t *images)
+{
 	ulong		mem_start;
 	phys_size_t	mem_size;
 
-	lmb_init(&images.lmb);
+	lmb_init(&images->lmb);
 
 	mem_start = getenv_bootm_low();
 	mem_size = getenv_bootm_size();
 
-	lmb_add(&images.lmb, (phys_addr_t)mem_start, mem_size);
+	lmb_add(&images->lmb, (phys_addr_t)mem_start, mem_size);
 
-	arch_lmb_reserve(&images.lmb);
-	board_lmb_reserve(&images.lmb);
+	arch_lmb_reserve(&images->lmb);
+	board_lmb_reserve(&images->lmb);
+}
 #else
-# define lmb_reserve(lmb, base, size)
+static inline void boot_start_lmb(bootm_headers_t *images) { }
 #endif
-}
 
 static int bootm_start(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
 {

@@ -197,7 +197,7 @@ static int bootm_start(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]
 	memset((void *)&images, 0, sizeof(images));
 	images.verify = getenv_yesno("verify");
 
-	bootm_start_lmb();
+	boot_start_lmb(&images);
 
 	/* get kernel image header, start address and length */
 	os_hdr = boot_get_kernel(cmdtp, flag, argc, argv,

@@ -1523,3 +1523,126 @@ static int do_bootm_integrity(int flag, int argc, char * const argv[],
 	return 1;
 }
 #endif
+
+#ifdef CONFIG_CMD_BOOTZ
+
+static int __bootz_setup(void *image, void **start, void **end)
+{
+	/* Please define bootz_setup() for your platform */
+
+	puts("Your platform's zImage format isn't supported yet!\n");
+	return -1;
+}
+int bootz_setup(void *image, void **start, void **end)
+	__attribute__((weak, alias("__bootz_setup")));
+
+/*
+ * zImage booting support
+ */
+static int bootz_start(cmd_tbl_t *cmdtp, int flag, int argc,
+			char * const argv[], bootm_headers_t *images)
+{
+	int ret;
+	void *zi_start, *zi_end;
+
+	memset(images, 0, sizeof(bootm_headers_t));
+
+	boot_start_lmb(images);
+
+	/* Setup Linux kernel zImage entry point */
+	if (argc < 2) {
+		images->ep = load_addr;
+		debug("*  kernel: default image load address = 0x%08lx\n",
+				load_addr);
+	} else {
+		images->ep = simple_strtoul(argv[1], NULL, 16);
+		debug("*  kernel: cmdline image address = 0x%08lx\n",
+			images->ep);
+	}
+
+	ret = bootz_setup((void *)images->ep, &zi_start, &zi_end);
+	if (ret != 0)
+		return 1;
+
+	lmb_reserve(&images->lmb, images->ep, zi_end - zi_start);
+
+	/* Find ramdisk */
+	ret = boot_get_ramdisk(argc, argv, images, IH_INITRD_ARCH,
+			&images->rd_start, &images->rd_end);
+	if (ret) {
+		puts("Ramdisk image is corrupt or invalid\n");
+		return 1;
+	}
+
+#if defined(CONFIG_OF_LIBFDT)
+	/* find flattened device tree */
+	ret = boot_get_fdt(flag, argc, argv, images,
+			   &images->ft_addr, &images->ft_len);
+	if (ret) {
+		puts("Could not find a valid device tree\n");
+		return 1;
+	}
+
+	set_working_fdt_addr(images->ft_addr);
+#endif
+
+	return 0;
+}
+
+static int do_bootz(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
+{
+	ulong		iflag;
+	bootm_headers_t	images;
+
+	if (bootz_start(cmdtp, flag, argc, argv, &images))
+		return 1;
+
+	/*
+	 * We have reached the point of no return: we are going to
+	 * overwrite all exception vector code, so we cannot easily
+	 * recover from any failures any more...
+	 */
+	iflag = disable_interrupts();
+
+#if defined(CONFIG_CMD_USB)
+	/*
+	 * turn off USB to prevent the host controller from writing to the
+	 * SDRAM while Linux is booting. This could happen (at least for OHCI
+	 * controller), because the HCCA (Host Controller Communication Area)
+	 * lies within the SDRAM and the host controller writes continously to
+	 * this area (as busmaster!). The HccaFrameNumber is for example
+	 * updated every 1 ms within the HCCA structure in SDRAM! For more
+	 * details see the OpenHCI specification.
+	 */
+	usb_stop();
+#endif
+
+#ifdef CONFIG_SILENT_CONSOLE
+	fixup_silent_linux();
+#endif
+	arch_preboot_os();
+
+	do_bootm_linux(0, argc, argv, &images);
+#ifdef DEBUG
+	puts("\n## Control returned to monitor - resetting...\n");
+#endif
+	do_reset(cmdtp, flag, argc, argv);
+
+	return 1;
+}
+
+U_BOOT_CMD(
+	bootz,	CONFIG_SYS_MAXARGS,	1,	do_bootz,
+	"boot Linux zImage image from memory",
+	"[addr [initrd] [fdt]]\n    - boot Linux zImage stored in memory\n"
+	"\tThe argument 'initrd' is optional and specifies the address\n"
+	"\tof the initrd in memory.\n"
+#if defined(CONFIG_OF_LIBFDT)
+	"\tWhen booting a Linux kernel which requires a flat device-tree\n"
+	"\ta third argument is required which is the address of the\n"
+	"\tdevice-tree blob. To boot that kernel without an initrd image,\n"
+	"\tuse a '-' for the second argument. If you do not pass a third\n"
+	"\ta bd_info struct will be passed instead\n"
+#endif
+);
+#endif	/* CONFIG_CMD_BOOTZ */

include/config_cmd_all.h +1 -0

index 9716f9c..2c6b829 100644
@@ -20,6 +20,7 @@
 #define CONFIG_CMD_BEDBUG	/* Include BedBug Debugger	*/
 #define CONFIG_CMD_BMP		/* BMP support			*/
 #define CONFIG_CMD_BOOTD	/* bootd			*/
+#define CONFIG_CMD_BOOTZ	/* boot zImage			*/
 #define CONFIG_CMD_BSP		/* Board Specific functions	*/
 #define CONFIG_CMD_CACHE	/* icache, dcache		*/
 #define CONFIG_CMD_CDP		/* Cisco Discovery Protocol	*/

Quoted 4 lines

From: Marek Vasut <[email protected]>

This command boots Linux zImage from where the zImage is loaded to. Passing initrd and fdt is supported.

This is great! However, the initrd is still in the u-boot image format, right?

If a raw initrd is supported, then we could get rid of flash-kernel on disk-based debian/ubuntu systems. The file size is known from the filesystem, but then needs to get to the bootz command somehow.

Dear Rob Herring,

Quoted 6 lines · Marek Vasut

Quoted 4 lines

From: Marek Vasut <[email protected]>

This command boots Linux zImage from where the zImage is loaded to. Passing initrd and fdt is supported.

Quoted 6 lines

This is great! However, the initrd is still in the u-boot image format, right?

If a raw initrd is supported, then we could get rid of flash-kernel on disk-based debian/ubuntu systems. The file size is known from the filesystem, but then needs to get to the bootz command somehow.

Yes. Initrd still needs a bit of work, ideas?

Quoted 8 lines

Dear Rob Herring,

Quoted 6 lines · Marek Vasut

Quoted 4 lines

From: Marek Vasut <[email protected]>

This command boots Linux zImage from where the zImage is loaded to. Passing initrd and fdt is supported.

Quoted 8 lines

Quoted 6 lines

This is great! However, the initrd is still in the u-boot image format, right?

If a raw initrd is supported, then we could get rid of flash-kernel on disk-based debian/ubuntu systems. The file size is known from the filesystem, but then needs to get to the bootz command somehow.

Yes. Initrd still needs a bit of work, ideas?

How about:

bootz <kern addr> [<fdt addr> [<initrd addr> [<initrd size>]]]

I changed the order so the size can be optional without resorting to using a "-". Then no size means u-boot image format.

File load commands would need to set loadsize env var.

Another idea is to prepend the u-boot image header on file loading. This would need some way to disable the crc check and specify any other data. It would probably be hard to do without changing existing commands.

Rob

Dear Rob Herring,

Quoted 12 lines · Marek Vasut

Quoted 11 lines

Dear Rob Herring,

Quoted 9 lines · Marek Vasut

Quoted 4 lines

From: Marek Vasut <[email protected]>

This command boots Linux zImage from where the zImage is loaded to. Passing initrd and fdt is supported.

This is great! However, the initrd is still in the u-boot image format, right?

Quoted 6 lines

Quoted 5 lines

Quoted 3 lines

If a raw initrd is supported, then we could get rid of flash-kernel on disk-based debian/ubuntu systems. The file size is known from the filesystem, but then needs to get to the bootz command somehow.

Yes. Initrd still needs a bit of work, ideas?

You lost some people in the Cc ;-)

Quoted 3 lines

How about:

bootz <kern addr> [<fdt addr> [<initrd addr> [<initrd size>]]]

What about bootz <kern addr> <initrd addr>[:<initrd size>] <fdt addr>

example: bootz 0x12000000 0x13000000:0x40000 0x14000000

Quoted 5 lines

I changed the order so the size can be optional without resorting to using a "-". Then no size means u-boot image format.

File load commands would need to set loadsize env var.

If you load kernel after initrd, that's screw things up.

Quoted 4 lines

Another idea is to prepend the u-boot image header on file loading. This would need some way to disable the crc check and specify any other data. It would probably be hard to do without changing existing commands.

Naw, this is weird. What do you think about my idea with the addr:size stuff?

Quoted 2 lines

Rob

Best regards,
Marek Vasut

Quoted 14 lines · Marek Vasut

Dear Rob Herring,

Quoted 12 lines · Marek Vasut

Quoted 11 lines

Dear Rob Herring,

Quoted 9 lines · Marek Vasut

Quoted 4 lines

From: Marek Vasut <[email protected]>

This command boots Linux zImage from where the zImage is loaded to. Passing initrd and fdt is supported.

This is great! However, the initrd is still in the u-boot image format, right?

Quoted 9 lines

Quoted 6 lines

Quoted 5 lines

Quoted 3 lines

If a raw initrd is supported, then we could get rid of flash-kernel on disk-based debian/ubuntu systems. The file size is known from the filesystem, but then needs to get to the bootz command somehow.

Yes. Initrd still needs a bit of work, ideas?

You lost some people in the Cc ;-)

They weren't in the original email header, only in the commit log as Cc's.

Quoted 8 lines

Quoted 3 lines

How about:

bootz <kern addr> [<fdt addr> [<initrd addr> [<initrd size>]]]

What about bootz <kern addr> <initrd addr>[:<initrd size>] <fdt addr>

example: bootz 0x12000000 0x13000000:0x40000 0x14000000

Sure. That works for me.

Quoted 4 lines

Quoted 4 lines

I changed the order so the size can be optional without resorting to using a "-". Then no size means u-boot image format.

Quoted 3 lines

Quoted 1 line

File load commands would need to set loadsize env var.

If you load kernel after initrd, that's screw things up.

Yes, but you already have to be aware of some commands which will change env vars. This has to be script-able to be useful. The only other way I see is adding a command to get the size of a file. Perhaps the ls commands when given a single file can do that.

Quoted 39 lines · Marek Vasut

Quoted 14 lines

Dear Rob Herring,

Quoted 12 lines · Marek Vasut

Quoted 11 lines

Dear Rob Herring,

Quoted 9 lines · Marek Vasut

Quoted 4 lines

From: Marek Vasut <[email protected]>

This command boots Linux zImage from where the zImage is loaded to. Passing initrd and fdt is supported.

This is great! However, the initrd is still in the u-boot image format, right?

Quoted 7 lines

Quoted 5 lines

Quoted 5 lines

Quoted 3 lines

If a raw initrd is supported, then we could get rid of flash-kernel on disk-based debian/ubuntu systems. The file size is known from the filesystem, but then needs to get to the bootz command somehow.

Yes. Initrd still needs a bit of work, ideas?

You lost some people in the Cc ;-)

They weren't in the original email header, only in the commit log as Cc's.

Quoted 7 lines

Quoted 3 lines

How about:

bootz <kern addr> [<fdt addr> [<initrd addr> [<initrd size>]]]

What about bootz <kern addr> <initrd addr>[:<initrd size>] <fdt addr>

example: bootz 0x12000000 0x13000000:0x40000 0x14000000

Sure. That works for me.

Quoted 3 lines

Quoted 3 lines

I changed the order so the size can be optional without resorting to using a "-". Then no size means u-boot image format.

Quoted 8 lines

Quoted 3 lines

Quoted 1 line

File load commands would need to set loadsize env var.

If you load kernel after initrd, that's screw things up.

Yes, but you already have to be aware of some commands which will change env vars. This has to be script-able to be useful. The only other way I see is adding a command to get the size of a file. Perhaps the ls commands when given a single file can do that.

Turns out there is already a filesize variable that gets set on file load commands.

And RTFM didn't help as that one is not documented... ;)

Turns out there is already a filesize variable that gets set on file load commands.

And RTFM didn't help as that one is not documented... ;)

Dear Rob Herring,

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

Turns out there is already a filesize variable that gets set on file load commands.

Quoted 1 line

And RTFM didn't help as that one is not documented... ;)

Are you sure? I'm pretty sure I can see it in the section of the manual that deals with environment variables. See
http://www.denx.de/wiki/view/DULG/UBootEnvVariables

You may have to scroll down to the end of the file.

How about:

bootz <kern addr> [<fdt addr> [<initrd addr> [<initrd size>]]]

I changed the order so the size can be optional without resorting to using a "-". Then no size means u-boot image format.

File load commands would need to set loadsize env var.

Another idea is to prepend the u-boot image header on file loading. This would need some way to disable the crc check and specify any other data.

It would probably be hard to do without changing existing commands.

From: Marek Vasut <[email protected]>

This command boots Linux zImage from where the zImage is loaded to. Passing initrd and fdt is supported.

Tested on i.MX28 based DENX M28EVK
Tested on PXA270 based Voipac PXA270.

NOTE: This currently only supports ARM, but other architectures can be easily added by defining bootz_setup().

Signed-off-by Marek Vasut <[email protected]>

Cc Tom Warren <[email protected]>

Cc albert.u.boot at aribaud.net

Cc afleming at gmail.com,

Cc Simon Glass <[email protected]>,

Cc Stephen Warren <[email protected]>

Cc Nicolas Pitre <[email protected]>

Cc Wolfgang Denk <[email protected]>

Cc Detlev Zundel <[email protected]>

---
 README                   |    8 +++
 arch/arm/lib/bootm.c     |   30 ++++++++++
 common/cmd_bootm.c       |  141 +++++++++++++++++++++++++++++++++++++++++++---
 include/config_cmd_all.h |    1 +
 4 files changed, 171 insertions(+), 9 deletions(-)

common/cmd_bootm.c +4 -4

 
-static void bootm_start_lmb(void)
-{
 #ifdef CONFIG_LMB
+static void boot_start_lmb(bootm_headers_t *images)
+{
 	ulong		mem_start;
 	phys_size_t	mem_size;
 
-	lmb_init(&images.lmb);
+	lmb_init(&images->lmb);
 
 	mem_start = getenv_bootm_low();
 	mem_size = getenv_bootm_size();
 
-	lmb_add(&images.lmb, (phys_addr_t)mem_start, mem_size);
+	lmb_add(&images->lmb, (phys_addr_t)mem_start, mem_size);
 

Quoted 27 lines

common/cmd_bootm.c +6 -6

 
-static void bootm_start_lmb(void)
-{
 
 #ifdef CONFIG_LMB
 
+static void boot_start_lmb(bootm_headers_t *images)
+{
 
 	ulong		mem_start;
 	phys_size_t	mem_size;
 
-	lmb_init(&images.lmb);
+	lmb_init(&images->lmb);
 
 	mem_start = getenv_bootm_low();
 	mem_size = getenv_bootm_size();
 
-	lmb_add(&images.lmb, (phys_addr_t)mem_start, mem_size);
+	lmb_add(&images->lmb, (phys_addr_t)mem_start, mem_size);
 
-	arch_lmb_reserve(&images.lmb);
-	board_lmb_reserve(&images.lmb);
+	arch_lmb_reserve(&images->lmb);
+	board_lmb_reserve(&images->lmb);

common/cmd_bootm.c

Quoted 10 lines

common/cmd_bootm.c +2 -2

+}
 
 #else
 
-# define lmb_reserve(lmb, base, size)
+static inline void boot_start_lmb(bootm_headers_t *images) { }
 
 #endif
 
-}

this breaks all non-lmb configs. before, lmb_reverse() was stubbed out, but now it's not, leading to build failures:

cmd_bootm.c: In function ?do_bootm_subcommand?:
cmd_bootm.c:518:23: error: ?bootm_headers_t? has no member named ?lmb? cmd_bootm.c: In function ?do_bootm?:
cmd_bootm.c:665:21: error: ?bootm_headers_t? has no member named ?lmb? make[2]: *** [cmd_bootm.o] Error 1
-mike

Dear Mike Frysinger,

Quoted 42 lines · On Thursday 15 March 2012 03:52:45 Marek Vasut wrote:

Quoted 27 lines

common/cmd_bootm.c +6 -6

 
-static void bootm_start_lmb(void)
-{
 
 #ifdef CONFIG_LMB
 
+static void boot_start_lmb(bootm_headers_t *images)
+{
 
 	ulong		mem_start;
 	phys_size_t	mem_size;
 
-	lmb_init(&images.lmb);
+	lmb_init(&images->lmb);
 
 	mem_start = getenv_bootm_low();
 	mem_size = getenv_bootm_size();
 
-	lmb_add(&images.lmb, (phys_addr_t)mem_start, mem_size);
+	lmb_add(&images->lmb, (phys_addr_t)mem_start, mem_size);
 
-	arch_lmb_reserve(&images.lmb);
-	board_lmb_reserve(&images.lmb);
+	arch_lmb_reserve(&images->lmb);
+	board_lmb_reserve(&images->lmb);

common/cmd_bootm.c

Quoted 10 lines

common/cmd_bootm.c +2 -2

+}
 
 #else
 
-# define lmb_reserve(lmb, base, size)
+static inline void boot_start_lmb(bootm_headers_t *images) { }
 
 #endif
 
-}

this breaks all non-lmb configs. before, lmb_reverse() was stubbed out, but now it's not, leading to build failures:

Quoted 6 lines

cmd_bootm.c: In function ?do_bootm_subcommand?:
cmd_bootm.c:518:23: error: ?bootm_headers_t? has no member named ?lmb? cmd_bootm.c: In function ?do_bootm?:
cmd_bootm.c:665:21: error: ?bootm_headers_t? has no member named ?lmb? make[2]: *** [cmd_bootm.o] Error 1
-mike

Well tested on arm/ppc ... can you submit patch for these platforms please ?

I'll be able to run mips/x86 next week.

Hi Marek,

Quoted 51 lines · Marek Vasut

Dear Mike Frysinger,

Quoted 42 lines · On Thursday 15 March 2012 03:52:45 Marek Vasut wrote:

Quoted 27 lines

common/cmd_bootm.c +6 -6

 
-static void bootm_start_lmb(void)
-{
 
 #ifdef CONFIG_LMB
 
+static void boot_start_lmb(bootm_headers_t *images)
+{
 
 	ulong		mem_start;
 	phys_size_t	mem_size;
 
-	lmb_init(&images.lmb);
+	lmb_init(&images->lmb);
 
 	mem_start = getenv_bootm_low();
 	mem_size = getenv_bootm_size();
 
-	lmb_add(&images.lmb, (phys_addr_t)mem_start, mem_size);
+	lmb_add(&images->lmb, (phys_addr_t)mem_start, mem_size);
 
-	arch_lmb_reserve(&images.lmb);
-	board_lmb_reserve(&images.lmb);
+	arch_lmb_reserve(&images->lmb);
+	board_lmb_reserve(&images->lmb);

common/cmd_bootm.c

Quoted 10 lines

common/cmd_bootm.c +2 -2

+}
 
 #else
 
-# define lmb_reserve(lmb, base, size)
+static inline void boot_start_lmb(bootm_headers_t *images) { }
 
 #endif
 
-}

this breaks all non-lmb configs. before, lmb_reverse() was stubbed out, but now it's not, leading to build failures:

Quoted 6 lines

cmd_bootm.c: In function ?do_bootm_subcommand?:
cmd_bootm.c:518:23: error: ?bootm_headers_t? has no member named ?lmb? cmd_bootm.c: In function ?do_bootm?:
cmd_bootm.c:665:21: error: ?bootm_headers_t? has no member named ?lmb? make[2]: *** [cmd_bootm.o] Error 1
-mike

Quoted 2 lines

Well tested on arm/ppc ... can you submit patch for these platforms please ?

I think the 'You Break, You Fix' rule applies ;)

Quoted 1 line

I'll be able to run mips/x86 next week.

Dang, I need it building now :P

I'm going to but in some really dodgy hacks just to get my build going again, but I would appreciate a fix ASAP

Regards,

Graeme