* Re: [PATCH] Add MPC8641 HPCN Device Tree Source file.
From: Hollis Blanchard @ 2006-08-02 19:50 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <1154544503.19994.42.camel@cashmere.sps.mot.com>
On Wed, 2006-08-02 at 13:48 -0500, Jon Loeliger wrote:
>
> + PowerPC,8641@0 {
> + device_type = "cpu";
> + reg = <0>;
> + d-cache-line-size = <20>; // 32 bytes
> + i-cache-line-size = <20>; // 32 bytes
> + d-cache-size = <8000>; // L1, 32K
> + i-cache-size = <8000>; // L1, 32K
> + timebase-frequency = <0>; // 33 MHz,
> from uboot
> + bus-frequency = <0>; // From uboot
> + clock-frequency = <0>; // From uboot
> + 32-bit;
> + linux,boot-cpu;
> + };
I need to do something similar for Xen, so I was curious: I guess the
preferred way for runtime software to fill in values is by *overwriting*
bogus values inserted at compile time?
The other alternative would be for the runtime code to insert new
properties (presumably via memmove()), but overwriting definitely seems
simpler.
-Hollis
^ permalink raw reply
* Re: [PATCH] Add MPC8641 HPCN Device Tree Source file.
From: Hollis Blanchard @ 2006-08-02 19:47 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <9C1B15CC-6984-433D-8A1E-F856567B1AD2@kernel.crashing.org>
On Wed, 2006-08-02 at 14:24 -0500, Kumar Gala wrote:
>
> Do we want to go ahead and fix the mac address field having the wrong
> name?
Yes please.
-Hollis
^ permalink raw reply
* Re: [PATCH] Add MPC8641 HPCN Device Tree Source file.
From: Kumar Gala @ 2006-08-02 20:30 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <1154549483.19994.46.camel@cashmere.sps.mot.com>
On Aug 2, 2006, at 3:11 PM, Jon Loeliger wrote:
> On Wed, 2006-08-02 at 14:24, Kumar Gala wrote:
>> On Aug 2, 2006, at 1:48 PM, Jon Loeliger wrote:
>>
>>> Signed-off-by: Jon Loeliger <jdl@freescale.com>
>>> ---
>>>
>>> As per list discussion, let's add device tree source files
>>> under powerpc/boot/dts. If nothing else, it is a starting point.
>>>
>>> arch/powerpc/boot/dts/mpc8641_hpcn.dts | 338 +++++++++++++++++++++
>>> +++++++++++
>>> 1 files changed, 338 insertions(+), 0 deletions(-)
>>
>> Do we want to go ahead and fix the mac address field having the wrong
>> name?
>>
>> - kumar
>
>
> Yeah, we have lined up Matt to make a comprehensive
> update for this. Can we take my patch as-is? Matt will
> follow up with a clean sweep, including fsl_socl.c, to
> fix it all in one swell foop.
I think this is one that is clearly something that should be fixed
before acceptance. Since we are talking about a dozen lines of
modifications. Especially since at this point having the .dts in the
tree doesn't really effect anything inside the kernel tree.
- kumar
>>> diff --git a/arch/powerpc/boot/dts/mpc8641_hpcn.dts b/arch/powerpc/
>>> boot/dts/mpc8641_hpcn.dts
>>> new file mode 100644
>>> index 0000000..55a8167
>>> --- /dev/null
>>> +++ b/arch/powerpc/boot/dts/mpc8641_hpcn.dts
>>> @@ -0,0 +1,338 @@
>>> +/*
>>> + * MPC8641 HPCN Device Tree Source
>>> + *
>
> Any chance we can avoid quoting-back the largely irrelevant
> parts of a post like this in the future?
>
> Thanks,
> jdl
>
>
^ permalink raw reply
* Re: [PATCH] Add MPC8641 HPCN Device Tree Source file.
From: Jon Loeliger @ 2006-08-02 20:36 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <BFD18279-7617-4F50-BB22-21A46C65FD50@kernel.crashing.org>
On Wed, 2006-08-02 at 15:30, Kumar Gala wrote:
> > Yeah, we have lined up Matt to make a comprehensive
> > update for this. Can we take my patch as-is? Matt will
> > follow up with a clean sweep, including fsl_socl.c, to
> > fix it all in one swell foop.
>
> I think this is one that is clearly something that should be fixed
> before acceptance. Since we are talking about a dozen lines of
> modifications. Especially since at this point having the .dts in the
> tree doesn't really effect anything inside the kernel tree.
>
> - kumar
On the other hand, this matches what the kernel implements
today, and is already in use by several people around the
world. It _does_ have an affect and is based on things
inside the kernel tree today as it is.
Thanks,
jdl
^ permalink raw reply
* Re: [PATCH] Add MPC8641 HPCN Device Tree Source file.
From: Mark A. Greer @ 2006-08-02 20:49 UTC (permalink / raw)
To: Hollis Blanchard; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <1154548217.32357.27.camel@basalt.austin.ibm.com>
On Wed, Aug 02, 2006 at 02:50:17PM -0500, Hollis Blanchard wrote:
> On Wed, 2006-08-02 at 13:48 -0500, Jon Loeliger wrote:
> >
> > + PowerPC,8641@0 {
> > + device_type = "cpu";
> > + reg = <0>;
> > + d-cache-line-size = <20>; // 32 bytes
> > + i-cache-line-size = <20>; // 32 bytes
> > + d-cache-size = <8000>; // L1, 32K
> > + i-cache-size = <8000>; // L1, 32K
> > + timebase-frequency = <0>; // 33 MHz,
> > from uboot
> > + bus-frequency = <0>; // From uboot
> > + clock-frequency = <0>; // From uboot
> > + 32-bit;
> > + linux,boot-cpu;
> > + };
>
> I need to do something similar for Xen, so I was curious: I guess the
> preferred way for runtime software to fill in values is by *overwriting*
> bogus values inserted at compile time?
>
> The other alternative would be for the runtime code to insert new
> properties (presumably via memmove()), but overwriting definitely seems
> simpler.
Two reasons you may want to overwrite instead of insert a new one (at
least for now):
1) Strictly opinion: Its nice to be able to see the completely
functional tree and not one that's missing a critical property
that is magically inserted behind the scenes.
2) Strictly practical for now: If you plan on using a zImage with
the fdt patches that are being discussed right now, the fdt code
doesn't currently support inserting a new property, only modifying an
existing one. Patches always welcome though! :)
Mark
^ permalink raw reply
* Re: [PATCH] Add MPC8641 HPCN Device Tree Source file.
From: Kumar Gala @ 2006-08-02 20:53 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <1154550970.19994.57.camel@cashmere.sps.mot.com>
On Aug 2, 2006, at 3:36 PM, Jon Loeliger wrote:
> On Wed, 2006-08-02 at 15:30, Kumar Gala wrote:
>
>>> Yeah, we have lined up Matt to make a comprehensive
>>> update for this. Can we take my patch as-is? Matt will
>>> follow up with a clean sweep, including fsl_socl.c, to
>>> fix it all in one swell foop.
>>
>> I think this is one that is clearly something that should be fixed
>> before acceptance. Since we are talking about a dozen lines of
>> modifications. Especially since at this point having the .dts in the
>> tree doesn't really effect anything inside the kernel tree.
>>
>> - kumar
>
> On the other hand, this matches what the kernel implements
> today, and is already in use by several people around the
> world. It _does_ have an affect and is based on things
> inside the kernel tree today as it is.
True, but the people that are running this dont really care if the
dts is in the kernel or not. I think having an error in the kernel
tree that we know about is more of an issue. Its something we all
agree needs to be fixed.
Here is the code modification to fsl_soc.c, I'm sure we can get this
fixed push into 2.6.18 if desired.
if(mac_addr = get_property(np, "address", NULL))
memcpy(gfar_data.mac_addr, mac_addr, 6);
if(mac_addr = get_property(np, "local-mac-address", NULL);
memcpy(gfar_data.mac_addr, mac_addr, 6);
- kumar
^ permalink raw reply
* [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
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