* [RFC] New target 'cuImage' - compatibility uImage
From: Matthew McClintock @ 2006-08-02 20:59 UTC (permalink / raw)
To: linuxppc-dev
Hi all,
The following is a patch which creates a new target called 'cuImage'. It
is designed to correctly package the kernel along with the
'arch/powerpc/boot' wrapper code into a uImage to be loaded and started
by U-Boot.
The purpose of this target is to allow boards with older versions of
U-Boot to utilize the 'bootm' command within U-Boot to run new powerpc
kernels. The bootwrapper will begin execution and can correctly setup a
flat device tree based on values passed in the bd_t structure, something
old versions of U-Boot are not capable of.
One might ask why not just use the 'bootelf' command in u-boot. Well,
not all boards have that option compiled in, and some other boards might
not even have access to the console. Also, the bd_t structure is not
passed from U-Boot when using the bootelf command so we would have no
method to correctly fill in values in the device tree. This would
theoretically allow an old board to start a new kernel without access to
the console if required.
Currently the zImage looks like this:
---------------------------------
- _start -
- boot wrapper code -
- ----------------------------- -
- - device tree - -
- ----------------------------- -
- ----------------------------- -
- - - -
- - compressed - -
- - kernel image - -
- - - -
- ----------------------------- -
---------------------------------
And the new cuImage will look like this:
-------------------------------------
- compressed uImage - -
- ------------------------------- - -
- - _start - - -
- - boot wrapper code - - -
- - ----------------------------- - -
- - - device tree - - -
- - ----------------------------- - -
- - ----------------------------- - -
- - - - - -
- - - UNcompressed - - -
- - - kernel image - - -
- - - - - -
- - ----------------------------- - -
- --------------------------------- -
-------------------------------------
-Matthew
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 13e583f..2d2c39a 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -96,11 +96,21 @@ config GENERIC_TBSYNC
default n
config DEFAULT_UIMAGE
- bool
+ bool "Set uImage to be the default build target"
help
Used to allow a board to specify it wants a uImage built by default
default n
+config UIMAGELOADADDR
+ hex "Set the uImage load address"
+ default 400000
+ depends on DEFAULT_UIMAGE
+
+config UIMAGEENTRY
+ hex "Set the uImage entry address"
+ default 400010
+ depends on DEFAULT_UIMAGE
+
menu "Processor support"compatibility
choice
prompt "Processor Type"
diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index 01667d1..eefbe16 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -141,12 +141,13 @@ # Default to zImage, override when neede
defaultimage-y := zImage
defaultimage-$(CONFIG_PPC_ISERIES) := vmlinux
defaultimage-$(CONFIG_DEFAULT_UIMAGE) := uImage
+defaultimage-$(CONFIG_DEFAULT_UIMAGE) := cuImage
KBUILD_IMAGE := $(defaultimage-y)
all: $(KBUILD_IMAGE)
CPPFLAGS_vmlinux.lds := -Upowerpc
-BOOT_TARGETS = zImage zImage.initrd znetboot znetboot.initrd vmlinux.sm
uImage vmlinux.bin
+BOOT_TARGETS = zImage zImage.initrd znetboot znetboot.initrd vmlinux.sm
uImage vmlinux.bin cuImage
PHONY += $(BOOT_TARGETS)
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index daad857..72e8ad8 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -23,7 +23,8 @@ # in the toplevel makefile.
HOSTCC := gcc
BOOTCFLAGS := $(HOSTCFLAGS) -fno-builtin -nostdinc -isystem \
- $(shell $(CROSS32CC) -print-file-name=include) -fPIC
+ $(shell $(CROSS32CC) -print-file-name=include) -fPIC \
+ -fno-schedule-insns -fno-schedule-insns2 -fno-inline
BOOTAFLAGS := -D__ASSEMBLY__ $(BOOTCFLAGS) -traditional -nostdinc
OBJCOPYFLAGS := contents,alloc,load,readonly,data
OBJCOPY_COFF_ARGS := -O aixcoff-rs6000 --set-start 0x500000
@@ -198,10 +199,18 @@ cmd_mygzip = gzip -f -9 < $< > $@.$$$$ &
quiet_cmd_objbin = OBJCOPY $@
cmd_objbin = $(OBJCOPY) -O binary $< $@
+ifndef CONFIG_UIMAGELOADADDR
+CONFIG_UIMAGELOADADDR = 00000000
+endif
+
+ifndef CONFIG_UIMAGEENTRY
+CONFIG_UIMAGEENTRY = 00000000
+endif
+
quiet_cmd_uimage = UIMAGE $@
cmd_uimage = $(CONFIG_SHELL) $(MKIMAGE) -A ppc -O linux -T kernel
\
- -C gzip -a 00000000 -e 00000000 -n
'Linux-$(KERNELRELEASE)' \
- -d $< $@
+ -C gzip -a $(CONFIG_UIMAGELOADADDR) -e $(CONFIG_UIMAGEENTRY) \
+ -n 'Linux-$(KERNELRELEASE)' -d $< $@
MKIMAGE := $(srctree)/scripts/mkuboot.sh
targets += uImage
@@ -223,3 +232,40 @@ install: $(CONFIGURE) $(BOOTIMAGE)
sh -x $(srctree)/$(src)/install.sh "$(KERNELRELEASE)" vmlinux
System.map "$(INSTALL_PATH)" "$(BOOTIMAGE)"
clean-files += $(addprefix $(objtree)/, $(obj-boot) vmlinux.strip)
+
+#-----------------------------------------------------------
+# build compatiblity u-boot images
+#-----------------------------------------------------------
+
+targets += cuImage
+
+quiet_cmd_addsection_cuimage = ADDSEC $@
+ cmd_addsection_cuimage = $(CROSS32OBJCOPY) $@ \
+ --add-section=.kernel:vmlinux.elf=vmlinux \
+ --set-section-flags=.kernel:vmlinux.elf=$(OBJCOPYFLAGS)
+
+$(obj)/kernel-compat.c:
+ @touch $@
+
+$(obj)/kernel-compat.o: $(obj)/kernel-compat.c vmlinux
+ $(call if_changed_dep,bootcc)
+ $(call cmd,addsection_cuimage)
+
+$(obj)/vmlinux-compat.elf: $(obj-boot) $(obj)/kernel-compat.o
+ $(call cmd,bootld,$(obj-boot) $(obj)/kernel-compat.o,cuImage.lds)
+
+$(obj)/vmlinux-compat.bin: $(obj)/vmlinux-compat.elf
+ $(call if_changed,objbin)
+
+$(obj)/vmlinux-compat.gz: $(obj)/vmlinux-compat.bin
+ $(call if_changed,mygzip)
+
+$(obj)/cuImage: $(obj)/vmlinux-compat.gz $(obj-boot)
+ $(Q)rm -f $@
+ $(call cmd,uimage)
+ @echo -n ' Image: $@ '
+ @if [ -f $@ ]; then echo 'is ready' ; else echo 'not made'; fi
+
+clean-files += vmlinux-compat.elf vmlinux-compat.bin vmlinux-compat.gz
cuImage
+
+
^ permalink raw reply related
* RE: Sloooooowwww CFI Flash programming
From: Frank @ 2006-08-02 22:12 UTC (permalink / raw)
To: Franca, Jose Filipe (ext), linuxppc-dev
In-Reply-To: <4051B1A83682514BA8529BCADDA45F086EE65A@PTLISI050MSX.PT001.SIEMENS.NET>
--- "Franca, Jose Filipe (ext)" <jose.franca.ext@siemens.com>
wrote:
> That is implemented in the 2.6 kernels. Are you sugesting a
> merge with
> 2.6 code? Or there is a patch that implements that in 2.4
> kernels?
>
> -----Original Message-----
> From: Frank [mailto:frannk_m1@yahoo.com]
> Sent: quarta-feira, 2 de Agosto de 2006 17:41
> To: Franca, Jose Filipe (ext); linuxppc-dev@ozlabs.org
> Subject: Re: Sloooooowwww CFI Flash programming
Look around, I've used buffered writes on a 2.4.25 kernel...
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* Re: [RFC] New target 'cuImage' - compatibility uImage
From: Wolfgang Denk @ 2006-08-02 22:33 UTC (permalink / raw)
To: Matthew McClintock; +Cc: linuxppc-dev
In-Reply-To: <1154552346.5550.51.camel@localhost>
In message <1154552346.5550.51.camel@localhost> you wrote:
>
> And the new cuImage will look like this:
>
> -------------------------------------
> - compressed uImage - -
> - ------------------------------- - -
> - - _start - - -
> - - boot wrapper code - - -
> - - ----------------------------- - -
> - - - device tree - - -
> - - ----------------------------- - -
> - - ----------------------------- - -
> - - - - - -
> - - - UNcompressed - - -
> - - - kernel image - - -
> - - - - - -
> - - ----------------------------- - -
> - --------------------------------- -
> -------------------------------------
Please explain.
In my understanding, an "uImage" file is a image consisting of an
U-Boot header (64 bytes) followed by an (compressed or uncompressed)
Linux kernel image.
So what do you mean by "compressed uImage"? If you take an "uImage"
file according to above definition and compress it, it will not be
recognized by U-Boot.
And why do you need a second, "UNcompressed kernel image" in your
setup? I must be missing something, because including *two* kernel
images makes no sense to me, and I don't understand why you would
want to insist of an "UNcompressed" image...
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
1st Old Man: Gee, its windy today.
2nd Old Man: No it's not... it's Thursday.
3rd Old Man: Yeh, me too. Let's go for a beer.
^ permalink raw reply
* Re: [RFC] New target 'cuImage' - compatibility uImage
From: Tom Rini @ 2006-08-03 0:30 UTC (permalink / raw)
To: Matthew McClintock; +Cc: linuxppc-dev
In-Reply-To: <1154552346.5550.51.camel@localhost>
On Wed, Aug 02, 2006 at 03:59:06PM -0500, Matthew McClintock wrote:
[snip]
> diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
> index 01667d1..eefbe16 100644
> --- a/arch/powerpc/Makefile
> +++ b/arch/powerpc/Makefile
> @@ -141,12 +141,13 @@ # Default to zImage, override when neede
> defaultimage-y := zImage
> defaultimage-$(CONFIG_PPC_ISERIES) := vmlinux
> defaultimage-$(CONFIG_DEFAULT_UIMAGE) := uImage
> +defaultimage-$(CONFIG_DEFAULT_UIMAGE) := cuImage
This means we never default to a regular 'uImage', and should either
modify the existing line, or a DEFAULT_CUIMAGE. No preference/etc, just
noting.
--
Tom Rini
^ permalink raw reply
* Re: RFC: Location for Device Tree Sources?
From: Tom Rini @ 2006-08-03 0:35 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-dev, Guennadi Liakhovetski
In-Reply-To: <20060802185153.GO17652@mag.az.mvista.com>
On Wed, Aug 02, 2006 at 11:51:53AM -0700, Mark A. Greer wrote:
> On Wed, Aug 02, 2006 at 01:41:51PM -0500, Brent Cook wrote:
> > On Wednesday 02 August 2006 13:22, Mark A. Greer wrote:
> > >
> > > Well, if you're going to keep prebuilt dtb files there, why wouldn't you
> > > want the dts that makes that dtb to be in the same place?
> > >
> > > Mark
> >
> > There is precedence for this. Look at drivers/net/ixp2000/, it includes both
> > the microengine source code, and the precompiled binary blob files (in case
> > you do not have the required assembler.)
>
> Interesting, but in our case everyone does have the compiler
> (or at least with little effort they do).
There are a few other cases of this, with the intention that if you're
mucking with these files you can regenerate. But we're just talking
about the blob in this part of the thread..
--
Tom Rini
^ permalink raw reply
* Re: [RFC] asm code for Hypervisor Call Instrumentation
From: Stephen Rothwell @ 2006-08-03 3:57 UTC (permalink / raw)
To: Mike Kravetz; +Cc: linuxppc-dev
In-Reply-To: <20060802175947.GA7489@w-mikek2.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 354 bytes --]
Hi Mike,
On Wed, 2 Aug 2006 10:59:47 -0700 Mike Kravetz <kravetz@us.ibm.com> wrote:
>
> +#else
> +
> +#define STACKFRAMESIZE 0
> +#define HCALL_INST_PRECALL nop
> +#define HCALL_INST_POSTCALL nop
Why even "nop", why not just blank?
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [RFC] asm code for Hypervisor Call Instrumentation
From: Mike Kravetz @ 2006-08-03 4:05 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev
In-Reply-To: <20060803135717.754bd37f.sfr@canb.auug.org.au>
On Thu, Aug 03, 2006 at 01:57:17PM +1000, Stephen Rothwell wrote:
> Hi Mike,
>
> On Wed, 2 Aug 2006 10:59:47 -0700 Mike Kravetz <kravetz@us.ibm.com> wrote:
> >
> > +#else
> > +
> > +#define STACKFRAMESIZE 0
> > +#define HCALL_INST_PRECALL nop
> > +#define HCALL_INST_POSTCALL nop
>
> Why even "nop", why not just blank?
At first I was concerned about macro expansion and knew a 'nop'
would be ok. Intended to go back and try 'blank', but forgot.
I'll give it a try.
--
Mike
^ permalink raw reply
* Re: [PATCH] clean up pseries hcall interfaces
From: Paul Mackerras @ 2006-08-03 4:06 UTC (permalink / raw)
To: Geoff Levand; +Cc: linuxppc-dev, Anton Blanchard
In-Reply-To: <44C68544.9000609@am.sony.com>
Geoff Levand writes:
> Change the scope of some pSeries routines now called through
> ppc_md to static.
With this I get:
CC arch/powerpc/platforms/pseries/lpar.o
/home/paulus/kernel/powerpc/arch/powerpc/platforms/pseries/lpar.c:273: error: static declaration of ‘pSeries_lpar_hpte_insert’ follows non-static declaration
include2/asm/mmu.h:254: error: previous declaration of ‘pSeries_lpar_hpte_insert’ was here
make[3]: *** [arch/powerpc/platforms/pseries/lpar.o] Error 1
make[2]: *** [arch/powerpc/platforms/pseries] Error 2
make[1]: *** [arch/powerpc/platforms] Error 2
make: *** [_all] Error 2
Paul.
^ permalink raw reply
* Re: [PATCH 1/6] bootwrapper: arch/powerpc/boot code reorg
From: Milton Miller @ 2006-08-03 5:57 UTC (permalink / raw)
To: paulus, mgreer, Linuxppc-dev
On Wed Aug 2 2006 01:15:05 AM CDT, Paul Mackerras wrote:
> I wrote:
>
> > The ops structure seems like a reasonable concept, but I question
> > whether we need to have platform_ops separate from fw_ops, since the
> > firmware is essentially part of the implementation of the platform.
> > Also I don't see why we need to do a double indirection to get to each
> > ops function.
>
> Thinking about this a bit more, why do we need the indirect function
> calls at all? Do we ever want to be able to choose (e.g.) one of
> several possible console implementations at runtime? Don't we know at
> compile time which one we will be using, and thus can't we use the
> linker to make the necessary linkages?
>
Personally, I would like to consider a zImage that could be either an open
firmware client or a kexec kernel. However, I'm not sure that requires the
full ops set. I just did the seperate image to get the function I needed quickly.
Also, were not some of the ops pre-existing?
milton
^ permalink raw reply
* Xilinx TEMAC
From: David H. Lynch Jr. @ 2006-08-03 6:35 UTC (permalink / raw)
To: Ameet Patil, edb, linuxppc-embedded
In-Reply-To: <44D07B38.5060700@gmail.com>
Ameet Patil wrote:
> > Did you happen to get an Ethernet mac going on the virtex2 or
> > virtex4 with the 2.6 kernel?
>
> Nope! :-(
> Rumour has it that Montavista is soon going to release the source for
> 2.6 kernel to run on Xilinx platforms.
>
>
I have 2 different TEMAC's working under 2.6 with a V4.
The MontaVista driver that has been posted on the list that I think
is from MontaVista for the PLB TEMAC with very minor modifications to
get it to work at speeds other than GigaBit.
A driver I wrote for the LocalLink TEMAC that works limpingly. I
have been unable to figure out how to get a receive interrupt from the
LocalLink TEMAC so receives are polled and performance is poor.
I have pretty much abandoned work on it - my client wants the
smallest possible FPGA footprint BUTanother OS I am porting requires
interrupt driven IO and we are looking for a single minimal hardware
implimentation for all platforms.
Anyway, if anyone wants the LL TEMAC in its current state I can post it.
Currently it sends fine. It drops about 50% of all received packets
- but that is probably debugging overhead and poll rate tuning.
--
Dave Lynch DLA Systems
Software Development: Embedded Linux
717.627.3770 dhlii@dlasys.net http://www.dlasys.net
fax: 1.253.369.9244 Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too numerous to list.
"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein
^ permalink raw reply
* Query regarding cicada PHYs
From: Alok Barsode @ 2006-08-03 6:47 UTC (permalink / raw)
To: Linuxppc-embedded
hi,
I am working on the MPC8555E dev board. It has a
Cicada 8204 (10/100/1000 Base-TX)PHY. I am not able to
find more info on this phy.(Cicada is taken over by
Vitesse?)
I wanted to know if 8204 PHY differs from 8201/8202
PHYs?
>From the gianfar driver, it appears that 8201 forms
some kind of auxillary ctrl/status register and is not
a complete PHY.I am not sure.
Where can i get the user programming manual for the
CIS8204?
Thanks,
Alok
"Let the wisdom of the old guide the buoyancy and vitality of the youth; let the buoyancy and vitality of the youth sustain the wisdom of the old." - Stanislavski
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* Re: [RFC] New target 'cuImage' - compatibility uImage
From: Milton Miller @ 2006-08-03 9:29 UTC (permalink / raw)
To: msm, linuxppc-dev
On Wed Aug 2 2006 03:59:06 PM CDT, Matthew McClintock wrote:
> The following is a patch which creates a new target called 'cuImage'. It
> is designed to correctly package the kernel along with the
> 'arch/powerpc/boot' wrapper code into a uImage to be loaded and started
> by U-Boot.
>
> The purpose of this target is to allow boards with older versions of
> U-Boot to utilize the 'bootm' command within U-Boot to run new powerpc
> kernels.
...
> And the new cuImage will look like this:
>
[add 'ompressed' uimage header and use uncompressed kernel]
Wolfgang already asked why you were using the uncompressed
kernel, and whart you meant by compressed uimage header.
Please describe when this would be used vs the existing uimage.
Can newer uboot boot the current uimage kernels?
>
> -Matthew
I'm going to switch styles here during the patch. I'll mark my comments
with leading ; on the line.
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 13e583f..2d2c39a 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -96,11 +96,21 @@ config GENERIC_TBSYNC
default n
config DEFAULT_UIMAGE
- bool
+ bool "Set uImage to be the default build target"
help
Used to allow a board to specify it wants a uImage built by default
default n
; If we are going to do this, it seems like this should be part of a choice or multiselect.
+config UIMAGELOADADDR
+ hex "Set the uImage load address"
+ default 400000
+ depends on DEFAULT_UIMAGE
+
+config UIMAGEENTRY
+ hex "Set the uImage entry address"
+ default 400010
+
; Make these questions, not the variables, the if clause to avoid the ifdef in the makefile.
:
: Is the entry point independent of the load address?
:
depends on DEFAULT_UIMAGE
+
menu "Processor support"compatibility
choice
prompt "Processor Type"
diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index 01667d1..eefbe16 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -141,12 +141,13 @@ # Default to zImage, override when neede
defaultimage-y := zImage
defaultimage-$(CONFIG_PPC_ISERIES) := vmlinux
defaultimage-$(CONFIG_DEFAULT_UIMAGE) := uImage
+defaultimage-$(CONFIG_DEFAULT_UIMAGE) := cuImage
; We need both?
KBUILD_IMAGE := $(defaultimage-y)
all: $(KBUILD_IMAGE)
CPPFLAGS_vmlinux.lds := -Upowerpc
-BOOT_TARGETS = zImage zImage.initrd znetboot znetboot.initrd vmlinux.sm
uImage vmlinux.bin
+BOOT_TARGETS = zImage zImage.initrd znetboot znetboot.initrd vmlinux.sm
uImage vmlinux.bin cuImage
PHONY += $(BOOT_TARGETS)
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index daad857..72e8ad8 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -23,7 +23,8 @@ # in the toplevel makefile.
HOSTCC := gcc
BOOTCFLAGS := $(HOSTCFLAGS) -fno-builtin -nostdinc -isystem \
- $(shell $(CROSS32CC) -print-file-name=include) -fPIC
+ $(shell $(CROSS32CC) -print-file-name=include) -fPIC \
+ -fno-schedule-insns -fno-schedule-insns2 -fno-inline
; Where did this come from? Seperate patch???
BOOTAFLAGS := -D__ASSEMBLY__ $(BOOTCFLAGS) -traditional -nostdinc
OBJCOPYFLAGS := contents,alloc,load,readonly,data
OBJCOPY_COFF_ARGS := -O aixcoff-rs6000 --set-start 0x500000
@@ -198,10 +199,18 @@ cmd_mygzip = gzip -f -9 < $< > $@.$$$$ &
quiet_cmd_objbin = OBJCOPY $@
cmd_objbin = $(OBJCOPY) -O binary $< $@
+ifndef CONFIG_UIMAGELOADADDR
+CONFIG_UIMAGELOADADDR = 00000000
+endif
+
+ifndef CONFIG_UIMAGEENTRY
+CONFIG_UIMAGEENTRY = 00000000
+endif
+
; See comments in Kconfig Or, we can leave them undefied if we aren't making this
quiet_cmd_uimage = UIMAGE $@
cmd_uimage = $(CONFIG_SHELL) $(MKIMAGE) -A ppc -O linux -T kernel
\
- -C gzip -a 00000000 -e 00000000 -n
'Linux-$(KERNELRELEASE)' \
- -d $< $@
+ -C gzip -a $(CONFIG_UIMAGELOADADDR) -e $(CONFIG_UIMAGEENTRY) \
+ -n 'Linux-$(KERNELRELEASE)' -d $< $@
MKIMAGE := $(srctree)/scripts/mkuboot.sh
targets += uImage
@@ -223,3 +232,40 @@ install: $(CONFIGURE) $(BOOTIMAGE)
sh -x $(srctree)/$(src)/install.sh "$(KERNELRELEASE)" vmlinux
System.map "$(INSTALL_PATH)" "$(BOOTIMAGE)"
clean-files += $(addprefix $(objtree)/, $(obj-boot) vmlinux.strip)
+
+#-----------------------------------------------------------
+# build compatiblity u-boot images
+#-----------------------------------------------------------
+
+targets += cuImage
+
+quiet_cmd_addsection_cuimage = ADDSEC $@
+ cmd_addsection_cuimage = $(CROSS32OBJCOPY) $@ \
+ --add-section=.kernel:vmlinux.elf=vmlinux \
+ --set-section-flags=.kernel:vmlinux.elf=$(OBJCOPYFLAGS)
+
+$(obj)/kernel-compat.c:
+ @touch $@
+
+$(obj)/kernel-compat.o: $(obj)/kernel-compat.c vmlinux
+ $(call if_changed_dep,bootcc)
+ $(call cmd,addsection_cuimage)
+
+$(obj)/vmlinux-compat.elf: $(obj-boot) $(obj)/kernel-compat.o
+ $(call cmd,bootld,$(obj-boot) $(obj)/kernel-compat.o,cuImage.lds)
+
+$(obj)/vmlinux-compat.bin: $(obj)/vmlinux-compat.elf
+ $(call if_changed,objbin)
+
+$(obj)/vmlinux-compat.gz: $(obj)/vmlinux-compat.bin
+ $(call if_changed,mygzip)
+
+$(obj)/cuImage: $(obj)/vmlinux-compat.gz $(obj-boot)
+ $(Q)rm -f $@
+ $(call cmd,uimage)
+ @echo -n ' Image: $@ '
+ @if [ -f $@ ]; then echo 'is ready' ; else echo 'not made'; fi
+
+clean-files += vmlinux-compat.elf vmlinux-compat.bin vmlinux-compat.gz
cuImage
+
+
^ permalink raw reply related
* Re: RFC: Location for Device Tree Sources?
From: Milton Miller @ 2006-08-03 9:32 UTC (permalink / raw)
To: trini, jdl; +Cc: linuxppc-dev, g.liakhovetski
On Wed Aug 2 2006 01:57:28 PM CDT, Tom Rini wrote:
> On Wed, Aug 02, 2006 at 01:23:08PM -0500, Jon Loeliger wrote:
> > On Wed, 2006-08-02 at 13:21, Tom Rini wrote:
> >
> > > Yes, as I said, I'm not totally sure we're at the stable point right
> > > now, but I think that we are. I'll add that maybe we need to think
> > > about API changes and DTS format versions. To quote from my post..
> > >
> > > > > X bugs) or a change that requires a dts version bump.
> >
> > Now it sounds like the IRQ thing was an "Oops, we should have changed
> > the dts version" and bailed, noting what is wrong with the dts.
> >
> > This confuses me.
...
> > Same (DTS) format
> > both before and after the IRQ changes.
> >
> > What have I missed here?
>
> Matthew said:
> > The sandpoint (as far as I know) does not have a stable DTS. So in this
> > case including the DTS in the kernel would reduce confusion. The same
> > could be said for other boards where the DTS needed to be changed for
> > the IRQ rework. The old DTS will no longer boot the new kernels. I'm not
> > sure how much longer we will run into this problem though.
>
> Now, if we've had to change the contents of the DTS because of a kernel
> change, I'd say the DTS format changed as when I say format I mean not
> only layout and naming, but what the contents are supposed to contain.
>
> And, so it's clear, I don't know if we're at the very stable format
> (names/layout/content means...), but when we are at that point, what
> Matthew noted should, IMHO, be a graceful (ie explained in the panic()
> or something) death.
>
> And, so it's clear, I think (and hope!) we all agree on that last part,
> once we hit stability.
I don't think we need to bump the dt version every time we make a tree
content requirements change. We need to bump when we add or
change fields in the struct header, change internal layout, or change how
we pass information through the tree. Certianly not because someone
left things out of their tree.
If we bump every time we check some new property, then the tools will
always be producing the wrong version and/or we will end up with trees
that claim they are good for some broad range that is really incompatable.
That being said, I haven't looked at what is now required. If we were to
eexpect some shim or preeparsing code to fixup existing trees then that
might warrant a version number beng assigned, if such information is not
readily determined by scanning the tree.
milton
^ permalink raw reply
* Re: Booting Linux Kernel without bootloader
From: Milton Miller @ 2006-08-03 7:48 UTC (permalink / raw)
To: grant.likely, cthomas; +Cc: linuxppc-embedded
On Tue Aug 1 2006 11:17:41 PM CDT, Grant Likely wrote:
> On 7/25/06, Clint Thomas <cthomas@soneticom.com> wrote:
> >
> > Basically, the system I want linux running on does not require the
> > initialization of hardware that U-boot provides, or at least it does not
> > need it to boot the linux kernel. I want to load an uncompressed linux
> > kernel into memory and start the execution of the kernel, without using any
> > kind of bootloader. Is this possible? Or does linux need some kind of
> > firmware or other software to tell it to start executing? Thanks for any
> > info you might have.
>
> Loading a kernel into memory and starting execution *is* a boot loader. :)
If it's running on the cpu, then I agreee. But he didn't say how he was loading
the image into memory, and if it is via an external agent then I would not
necessarly call that a boot loader, altough it is performing those tasks.
Actually, that may be too broad. Is kexec a boot loader?
>
> You could use the bootwrapper that is in the kernel source tree
> (zImage). If a zImage's entry point is at the execution entry point,
> then it will start the Linux kernel correctly. However, it is still a
> compressed image.
>
The boot wrapper is a reference implementation, not a required piece of the
boot sequence. As I stated in my previous post, the kernel entry conditions
are documted and loading the vmlinux raw is reasonable, asssuming that
the other conditions can be met (registers and device treee, and maybe
initrd).
> If you *really* need an uncompressed image, I would start with the
> bootwrapper and hack it to work with an non-gzipped kernel image.
> However, why do you want to do it this way? You probably won't gain
> much in boot time and it will be more difficult to maintain.
Actually, the code is aready there to just copy anything inthe kernel
section that is without the gzip header.
milton
^ permalink raw reply
* RE: [RFC] New target 'cuImage' - compatibility uImage
From: Li Yang-r58472 @ 2006-08-03 11:38 UTC (permalink / raw)
To: Wolfgang Denk, McClintock Matthew-R56630; +Cc: linuxppc-dev
In-Reply-To: <20060802223302.9667135360F@atlas.denx.de>
> -----Original Message-----
> From: linuxppc-dev-bounces+leoli=3Dfreescale.com@ozlabs.org
> [mailto:linuxppc-dev-bounces+leoli=3Dfreescale.com@ozlabs.org] On =
Behalf
Of
> Wolfgang Denk
> Sent: Thursday, August 03, 2006 6:33 AM
> To: McClintock Matthew-R56630
> Cc: linuxppc-dev
> Subject: Re: [RFC] New target 'cuImage' - compatibility uImage
>=20
> In message <1154552346.5550.51.camel@localhost> you wrote:
> >
> > And the new cuImage will look like this:
> >
> > -------------------------------------
> > - compressed uImage - -
> > - ------------------------------- - -
> > - - _start - - -
> > - - boot wrapper code - - -
> > - - ----------------------------- - -
> > - - - device tree - - -
> > - - ----------------------------- - -
> > - - ----------------------------- - -
> > - - - - - -
> > - - - UNcompressed - - -
> > - - - kernel image - - -
> > - - - - - -
> > - - ----------------------------- - -
> > - --------------------------------- -
> > -------------------------------------
>=20
> Please explain.
>=20
> In my understanding, an "uImage" file is a image consisting of an
> U-Boot header (64 bytes) followed by an (compressed or uncompressed)
> Linux kernel image.
>=20
> So what do you mean by "compressed uImage"? If you take an "uImage"
> file according to above definition and compress it, it will not be
> recognized by U-Boot.
I don't know if my understanding is exactly what Matt means. But the
compressed uImage seems to be (u-boot header + compress(wrapper + FDT +
kernel image)), instead of original (u-boot header + compress(kernel
image)). A better naming probably is needed to prevent misleading.
>=20
> And why do you need a second, "UNcompressed kernel image" in your
> setup? I must be missing something, because including *two* kernel
> images makes no sense to me, and I don't understand why you would
> want to insist of an "UNcompressed" image...
>=20
> Best regards,
>=20
> Wolfgang Denk
^ permalink raw reply
* RE: [RFC] New target 'cuImage' - compatibility uImage
From: Li Yang-r58472 @ 2006-08-03 11:47 UTC (permalink / raw)
To: McClintock Matthew-R56630, linuxppc-dev
In-Reply-To: <1154552346.5550.51.camel@localhost>
If my understanding to Matt's idea is correct, it will be a good way,
IMHO. How about use the naming of uwImage(U-boot Wrapped Image) or
utImage(u-boot device-Tree Image).
-Leo
> -----Original Message-----
> From: linuxppc-dev-bounces+leoli=3Dfreescale.com@ozlabs.org
> [mailto:linuxppc-dev-bounces+leoli=3Dfreescale.com@ozlabs.org] On =
Behalf
Of
> Matthew McClintock
> Sent: Thursday, August 03, 2006 4:59 AM
> To: linuxppc-dev
> Subject: [RFC] New target 'cuImage' - compatibility uImage
>=20
> Hi all,
>=20
> The following is a patch which creates a new target called 'cuImage'.
It
> is designed to correctly package the kernel along with the
> 'arch/powerpc/boot' wrapper code into a uImage to be loaded and
started
> by U-Boot.
>=20
> The purpose of this target is to allow boards with older versions of
> U-Boot to utilize the 'bootm' command within U-Boot to run new powerpc
> kernels. The bootwrapper will begin execution and can correctly setup
a
> flat device tree based on values passed in the bd_t structure,
something
> old versions of U-Boot are not capable of.
>=20
> One might ask why not just use the 'bootelf' command in u-boot. Well,
> not all boards have that option compiled in, and some other boards
might
> not even have access to the console. Also, the bd_t structure is not
> passed from U-Boot when using the bootelf command so we would have no
> method to correctly fill in values in the device tree. This would
> theoretically allow an old board to start a new kernel without access
to
> the console if required.
>=20
> Currently the zImage looks like this:
>=20
> ---------------------------------
> - _start -
> - boot wrapper code -
> - ----------------------------- -
> - - device tree - -
> - ----------------------------- -
> - ----------------------------- -
> - - - -
> - - compressed - -
> - - kernel image - -
> - - - -
> - ----------------------------- -
> ---------------------------------
>=20
> And the new cuImage will look like this:
>=20
> -------------------------------------
> - compressed uImage - -
> - ------------------------------- - -
> - - _start - - -
> - - boot wrapper code - - -
> - - ----------------------------- - -
> - - - device tree - - -
> - - ----------------------------- - -
> - - ----------------------------- - -
> - - - - - -
> - - - UNcompressed - - -
> - - - kernel image - - -
> - - - - - -
> - - ----------------------------- - -
> - --------------------------------- -
> -------------------------------------
>=20
> -Matthew
>=20
^ permalink raw reply
* IBM OCP GPIO driver for linux 2.6
From: Jean-Baptiste Maneyrol @ 2006-08-03 11:15 UTC (permalink / raw)
To: linuxppc-embedded
Hello everyone, I'm a newbie here!
I'm porting a custom PPC 405GP card based on a Walnut from Montavista
Linux 3.0 (kernel 2.4.18) to linux 2.6, and I was wondering if there is
a port of the IBM OCP GPIO driver (a char driver providing
device /dev/gpio, major 10 minor 185). The driver was written by Armin
Kuster, and it doesn't exist in the stock kernel 2.6.17.7.
Let me known if a port exists, or if there is a new way of accessing the
PPC 405GP GPIO under linux 2.6. Otherwise, I will port this driver using
the IBM IIC driver as an example (for the things about OCP). In this
case, do anybody know where I can have the last version of this driver
(I have v 1.7 (07/25/02)) ?
Thanks for all!
Jean-Baptiste Maneyrol
Teamlog - France
^ permalink raw reply
* Re: IBM OCP GPIO driver for linux 2.6
From: Dale Farnsworth @ 2006-08-03 13:53 UTC (permalink / raw)
To: jean-baptiste.maneyrol, Linuxppc-embedded
In-Reply-To: <1154603751.17247.10.camel@jb-portable>
In article <1154603751.17247.10.camel@jb-portable> you write:
> I'm porting a custom PPC 405GP card based on a Walnut from Montavista
> Linux 3.0 (kernel 2.4.18) to linux 2.6, and I was wondering if there is
> a port of the IBM OCP GPIO driver (a char driver providing
> device /dev/gpio, major 10 minor 185). The driver was written by Armin
> Kuster, and it doesn't exist in the stock kernel 2.6.17.7.
>
> Let me known if a port exists, or if there is a new way of accessing the
> PPC 405GP GPIO under linux 2.6.
The recommended way of accessing GPIO registers is to mmap them
and manipulate them directly in user space.
Below, I've included a quick hack that blinks a LED on a Walnut-like
board.
-Dale
#include <stdint.h>
#include <stdio.h>
#include <sys/mman.h>
#include <sys/types.h>
#include <unistd.h>
#include <sys/stat.h>
#include <fcntl.h>
#define GPIO_PAGE_ADDR 0xef600000
#define OUTPUT_REG 0x0700
#define TRISTATE_REG 0x0704
#define OPENDRAIN_REG 0x0718
#define INPUT_REG 0x071c
#define MEDIA_LED_BIT 0x20000000
#define reg_addr(p, o) ((uint32_t *)((void *)p + o))
int main(int argc, char *argv[])
{
int i;
uint32_t *p;
char *filename = "/dev/mem";
void *addr = 0;
size_t length = 4096;
int prot = PROT_READ | PROT_WRITE;
int flags = MAP_SHARED;
int fd = open(filename, O_RDWR);
off_t offset = (off_t)GPIO_PAGE_ADDR;
if (fd < 0) {
perror("open");
return 1;
}
p = mmap(addr, length, prot, flags, fd, offset);
if (p == MAP_FAILED) {
perror("mmap");
return 4;
}
/* drive led output */
*reg_addr(p, TRISTATE_REG) |= MEDIA_LED_BIT;
/* blink media led 10 times */
for (i = 0; i < 10; i++) {
/* turn media led on */
*reg_addr(p, OUTPUT_REG) &= ~MEDIA_LED_BIT;
sleep(1);
/* turn media led off */
*reg_addr(p, OUTPUT_REG) |= MEDIA_LED_BIT;
sleep(1);
}
return 0;
}
^ permalink raw reply
* Re: RFC: Location for Device Tree Sources?
From: Tom Rini @ 2006-08-03 13:54 UTC (permalink / raw)
To: Milton Miller; +Cc: linuxppc-dev, g.liakhovetski
In-Reply-To: <3115459755319495cff4.1649760492.miltonm@bga.com>
On Thu, Aug 03, 2006 at 04:32:33AM -0500, Milton Miller wrote:
> I don't think we need to bump the dt version every time we make a tree
> content requirements change. We need to bump when we add or
> change fields in the struct header, change internal layout, or change how
> we pass information through the tree. Certianly not because someone
> left things out of their tree.
But "content requirements change" isn't the same as "left things out of
their tree". It sounds, and I haven't seen the changes, so I'm not
certain that the meaning behind a field changed. Something like that
should change the dt version. New fields aren't a problem. Changing
existing fields meaning in incompatible ways is a problem.
--
Tom Rini
^ permalink raw reply
* Re: IBM OCP GPIO driver for linux 2.6
From: Arnd Bergmann @ 2006-08-03 13:54 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: Jean-Baptiste Maneyrol
In-Reply-To: <1154603751.17247.10.camel@jb-portable>
On Thursday 03 August 2006 13:15, Jean-Baptiste Maneyrol wrote:
> Let me known if a port exists, or if there is a new way of accessing the
> PPC 405GP GPIO under linux 2.6. Otherwise, I will port this driver using
> the IBM IIC driver as an example (for the things about OCP). In this
> case, do anybody know where I can have the last version of this driver
> (I have v 1.7 (07/25/02)) ?
The only OCP drivers that exist in the tree are for emac and iic.
Those will probably be converted to use something like of_platform_device
in the future, as soon as 4xx gets converted to arch/powerpc.
If you need to port the driver now, it's probably a good idea to use
a platform_driver instead of an ocp driver for it.
Arnd <><
^ permalink raw reply
* Re: problems with mounting JFFS2 using CFI for AM29LV160MT on ppc8245 k2.4.x
From: Ben Warren @ 2006-08-03 14:18 UTC (permalink / raw)
To: Arun Kumar; +Cc: linuxppc-embedded
In-Reply-To: <edd12c050607260503y58808ecrdbee205fa4e617b3@mail.gmail.com>
Arun,
Please keep the mailing list CC'd on all correspondence. As you can
see, I've been busy for the past week and am sure there are others
listening that are more qualified to answer. Anyway...
On Wed, 2006-07-26 at 17:33 +0530, Arun Kumar wrote:
> Hi Ben ,
> I guess this is the last stage before bringing the flash up .
>
> I am able to partition and open the particular partition agere-ets1 in
> Vi editor .(without NFS)
> after enabling the MTD_CHAR and MTD_BLOCK support .
> When I ttry to save the file /text file I get an internal flash
> timeout error .I have programmed my uWriteTiemout to be 500 .
>
> I am sending a dump of the out put and the cfi_cmdset002.c as well as
> the .config file snapshots .
>
> Please take a look :-)
> It seems the code on bringup disables fast programming .
Looks like you now have char-based reads working, so I expect your
kernel is now properly configured. The AMD chip you're using has been
around for a while, so it's unlikely a source-code problem.
Have you tried mtd-utils? If not, I recommend installing them on the
board. The source as well as RPMs are available on-line at a number of
places. Google will help you here.
regards,
Ben
^ permalink raw reply
* Re: Booting Linux Kernel without bootloader
From: Grant Likely @ 2006-08-03 14:34 UTC (permalink / raw)
To: Milton Miller; +Cc: linuxppc-embedded
In-Reply-To: <311545913012eb141f24.1102520059.miltonm@bga.com>
On 8/3/06, Milton Miller <miltonm@bga.com> wrote:
> On Tue Aug 1 2006 11:17:41 PM CDT, Grant Likely wrote:
> > On 7/25/06, Clint Thomas <cthomas@soneticom.com> wrote:
> > >
> > > Basically, the system I want linux running on does not require the
> > > initialization of hardware that U-boot provides, or at least it does not
> > > need it to boot the linux kernel. I want to load an uncompressed linux
> > > kernel into memory and start the execution of the kernel, without using any
> > > kind of bootloader. Is this possible? Or does linux need some kind of
> > > firmware or other software to tell it to start executing? Thanks for any
> > > info you might have.
> >
> > Loading a kernel into memory and starting execution *is* a boot loader. :)
>
> If it's running on the cpu, then I agreee. But he didn't say how he was loading
> the image into memory, and if it is via an external agent then I would not
> necessarly call that a boot loader, altough it is performing those tasks.
> Actually, that may be too broad. Is kexec a boot loader?
I would say it is. :)
IMHO, even the basic tasks of correctly setting up the initial
conditions can be considered a bootloader.
> > You could use the bootwrapper that is in the kernel source tree
> > (zImage). If a zImage's entry point is at the execution entry point,
> > then it will start the Linux kernel correctly. However, it is still a
> > compressed image.
> >
>
> The boot wrapper is a reference implementation, not a required piece of the
> boot sequence. As I stated in my previous post, the kernel entry conditions
> are documted and loading the vmlinux raw is reasonable, asssuming that
> the other conditions can be met (registers and device treee, and maybe
> initrd).
I agree. However, the original post sounded to me like he was looking
for a canned solution. I know zImage isn't exactly what he asked for
because it is a compressed image, but it does achieve the *effect* he
asked for.
I am curious as to the source of his requirements. ie. what is
loading the kernel into ram? Where is it coming from?
I've got a similar situation on my Virtex-4 platform. The FPGA takes
care of all device initialization. However, the kernel is loaded of a
CF card via a *slow* JTAG interface. Loading an uncompressed image is
more time consuming than loading a compressed image and uncompressing
it in software.
>
> > If you *really* need an uncompressed image, I would start with the
> > bootwrapper and hack it to work with an non-gzipped kernel image.
> > However, why do you want to do it this way? You probably won't gain
> > much in boot time and it will be more difficult to maintain.
>
> Actually, the code is aready there to just copy anything inthe kernel
> section that is without the gzip header.
Perfect!
cheers,
g.
--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: RFC: Location for Device Tree Sources?
From: Li Yang @ 2006-08-03 14:49 UTC (permalink / raw)
To: Kumar Gala; +Cc: Tom Rini, Guennadi Liakhovetski, linuxppc-dev@ozlabs.org
In-Reply-To: <A6047A42-78C4-4B38-B7B1-77B2C6E9A5CC@kernel.crashing.org>
On 8/3/06, Kumar Gala <galak@kernel.crashing.org> wrote:
>
> On Aug 2, 2006, at 1:57 PM, Tom Rini wrote:
>
> > On Wed, Aug 02, 2006 at 01:23:08PM -0500, Jon Loeliger wrote:
> >> On Wed, 2006-08-02 at 13:21, Tom Rini wrote:
> >>
> >>> Yes, as I said, I'm not totally sure we're at the stable point right
> >>> now, but I think that we are. I'll add that maybe we need to think
> >>> about API changes and DTS format versions. To quote from my post..
> >>>
> >>>>> X bugs) or a change that requires a dts version bump.
> >>>
> >>> Now it sounds like the IRQ thing was an "Oops, we should have
> >>> changed
> >>> the dts version" and bailed, noting what is wrong with the dts.
> >>
> >> This confuses me. There hasn't been a change in the DTS
> >> format at all. I've even updated the 8641HPCN DTS file
> >> across the IRQ updates and all is fine. Same (DTS) format
> >> both before and after the IRQ changes.
> >>
> >> What have I missed here?
> >
> > Matthew said:
> >> The sandpoint (as far as I know) does not have a stable DTS. So in
> >> this
> >> case including the DTS in the kernel would reduce confusion. The same
> >> could be said for other boards where the DTS needed to be changed for
> >> the IRQ rework. The old DTS will no longer boot the new kernels.
> >> I'm not
> >> sure how much longer we will run into this problem though.
> >
> > Now, if we've had to change the contents of the DTS because of a
> > kernel
> > change, I'd say the DTS format changed as when I say format I mean not
> > only layout and naming, but what the contents are supposed to contain.
> >
> > And, so it's clear, I don't know if we're at the very stable format
> > (names/layout/content means...), but when we are at that point, what
> > Matthew noted should, IMHO, be a graceful (ie explained in the panic()
> > or something) death.
> >
> > And, so it's clear, I think (and hope!) we all agree on that last
> > part,
> > once we hit stability.
>
> Agree about the comments related to the stability of the API, I just
> dont think we are there yet. We should revisit the issue when we
> removed arch/ppc, until that point I would say things are up in the air.
>
> For example, we still haven't closed on CPM descriptions and I'm sure
> we will go through several iterations before we get it right. For
> more standard things like uart's, ethernet, pci we have the OF specs
> to model off of and are probably pretty stable.
I agree. We are adding more and more device types under device tree
management. There will be a process of evolution.
>
> Additionally, Ben and I have talked about making macro's in the dts's
> so we can build up a board or SOC description from standard building
> blocks so people dont get the simple things wrong.
What are the macros about? Like constant we used in source code?
>
> - kumar
- Leo
^ permalink raw reply
* DMA Driver on MPC8260
From: jimmy liu @ 2006-08-03 15:21 UTC (permalink / raw)
To: linuxppc-embedded
I am working on PCI transactions between MPC8260 and
FPGA. Could somebody give me some information about
the PCI DMA Driver on MPC8260?
Thanks.
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* Re: [RFC] New target 'cuImage' - compatibility uImage
From: Matthew McClintock @ 2006-08-03 15:24 UTC (permalink / raw)
To: Tom Rini; +Cc: linuxppc-dev
In-Reply-To: <20060803003015.GX3075@smtp.west.cox.net>
On Wed, 2006-08-02 at 17:30 -0700, Tom Rini wrote:
> On Wed, Aug 02, 2006 at 03:59:06PM -0500, Matthew McClintock wrote:
>
> [snip]
> > diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
> > index 01667d1..eefbe16 100644
> > --- a/arch/powerpc/Makefile
> > +++ b/arch/powerpc/Makefile
> > @@ -141,12 +141,13 @@ # Default to zImage, override when neede
> > defaultimage-y := zImage
> > defaultimage-$(CONFIG_PPC_ISERIES) := vmlinux
> > defaultimage-$(CONFIG_DEFAULT_UIMAGE) := uImage
> > +defaultimage-$(CONFIG_DEFAULT_UIMAGE) := cuImage
>
> This means we never default to a regular 'uImage', and should either
> modify the existing line, or a DEFAULT_CUIMAGE. No preference/etc, just
> noting.
>
Note taken, if I ever submit a formal patch I will be sure to include
this.
Thanks,
Matthew
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox