* Re: RFC/slightly offtopic: Automatic patchwork status updates
From: Michael Neuling @ 2006-09-27 6:26 UTC (permalink / raw)
To: Jeremy Kerr; +Cc: linuxppc-dev, cbe-oss-dev, Troy Rollo
In-Reply-To: <200609271528.49260.jk@ozlabs.org>
> For some time now, we've been running patchwork on the linuxppc and
> cbe-oss-dev lists. For those who haven't seen it, it collects and
> tracks patches posted to the lists, and shows them here:
>
> http://patchwork.ozlabs.org/linuxppc
> and
> http://patchwork.ozlabs.org/cbe-oss-dev
>
> However, the patch 'state' (eg, accepted, rejected, debug only, changes
> requested) doesn't get updated very often, as it can be an unnecessary
> burden on the maintainers.
>
> All this information is available from the actual upstream tree itself,
> so essentially patchwork *should* be able to just mirror the state.
Personally, I use the git web server on kernel.org to see if my patches
are in a particular tree. I have a bookmark something like this:
http://git.kernel.org/git/?p=linux/kernel/git/paulus/powerpc.git&a=search&h=HEAD&s=Jeremy+Kerr
This may not solve all the problems you are trying to solve with
patchworks though.
Mikey
^ permalink raw reply
* Re: [PATCH 10/11] Add MPC8360EMDS board support
From: Paul Mackerras @ 2006-09-27 6:39 UTC (permalink / raw)
To: Li Yang; +Cc: linuxppc-dev
In-Reply-To: <45128378.7090508@freescale.com>
Li Yang writes:
> +#define BCSR_PHYS_ADDR ((uint)0xf8000000)
> +#define BCSR_SIZE ((uint)(32 * 1024))
This sort of thing should really be in the device tree.
Paul.
^ permalink raw reply
* [PATCH] Use check_legacy_ioport() for ISAPnP
From: David Woodhouse @ 2006-09-27 7:18 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
diff --git a/drivers/pnp/isapnp/core.c b/drivers/pnp/isapnp/core.c
index f2e0179..3ac5b12 100644
--- a/drivers/pnp/isapnp/core.c
+++ b/drivers/pnp/isapnp/core.c
@@ -1049,6 +1049,10 @@ static int __init isapnp_init(void)
printk(KERN_INFO "isapnp: ISA Plug & Play support disabled\n");
return 0;
}
+#ifdef CONFIG_PPC_MERGE
+ if (check_legacy_ioport(_PIDXR) || check_legacy_ioport(_PNPWRP))
+ return -EINVAL;
+#endif
#ifdef ISAPNP_REGION_OK
if (!request_region(_PIDXR, 1, "isapnp index")) {
printk(KERN_ERR "isapnp: Index Register 0x%x already used\n", _PIDXR);
--
dwmw2
^ permalink raw reply related
* Re: [PATCH] Use check_legacy_ioport() for ISAPnP
From: Olaf Hering @ 2006-09-27 8:18 UTC (permalink / raw)
To: David Woodhouse; +Cc: linuxppc-dev, paulus
In-Reply-To: <1159341535.3309.108.camel@pmac.infradead.org>
On Wed, Sep 27, David Woodhouse wrote:
> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
>
> diff --git a/drivers/pnp/isapnp/core.c b/drivers/pnp/isapnp/core.c
> index f2e0179..3ac5b12 100644
> --- a/drivers/pnp/isapnp/core.c
> +++ b/drivers/pnp/isapnp/core.c
> @@ -1049,6 +1049,10 @@ static int __init isapnp_init(void)
> printk(KERN_INFO "isapnp: ISA Plug & Play support disabled\n");
> return 0;
> }
> +#ifdef CONFIG_PPC_MERGE
> + if (check_legacy_ioport(_PIDXR) || check_legacy_ioport(_PNPWRP))
> + return -EINVAL;
> +#endif
> #ifdef ISAPNP_REGION_OK
> if (!request_region(_PIDXR, 1, "isapnp index")) {
> printk(KERN_ERR "isapnp: Index Register 0x%x already used\n", _PIDXR);
Isnt that fixed by my other patch which was merged into -mm today?
^ permalink raw reply
* Re: [PATCH] move drivers/macintosh variables to BSS
From: Olaf Hering @ 2006-09-27 9:12 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Paul Mackeras
In-Reply-To: <1159310719.4435.41.camel@localhost.localdomain>
On Wed, Sep 27, Benjamin Herrenschmidt wrote:
> On Tue, 2006-09-26 at 22:15 +0200, Olaf Hering wrote:
> > Move all the initialized variables to bss and init them at runtime if needed.
> > Mark a version string as const.
>
> What is the point of that ?
Globals are automatically set to zero, or what do you mean?
^ permalink raw reply
* SM722 (Lynx3DM+) framebuffer driver
From: Matthias Fuchs @ 2006-09-27 10:26 UTC (permalink / raw)
To: Linuxppc-embedded
Hi,
does anyone know about a Silicon Motion SM722 framebuffer driver for recent
2.6 kernels? I found some old and dusty code for the Silicon Motion parts but
either only for the SM712 or for 2.4 kernels.
Is anyone using that part in a PowerPC system?
Matthias
^ permalink raw reply
* Re: Need help to write I2C EEPROM device driver
From: Matthias Fuchs @ 2006-09-27 10:21 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: Sachin Rane
In-Reply-To: <8584FDC94AFF7640B17B8A89B23B19B34F658F@sbsserver.AlphionCorp.local>
Hi Sachin,
there is already a driver for this part in the kernel
(drivers/i2c/chips/eeprom.c).
BTW: to do some simple reads and writes to an I2C EEPROM it is very simple to
access the EEPROM via read/write/ioctl through /dev/i2c-<x>. No driver - only
userland code.
Matthias
On Tuesday 26 September 2006 16:34, Sachin Rane wrote:
> Hi,
>
> I am looking for an information to write a device driver to access EEPROM IC
M24C02-WBN6.
> The EEPROM IC M24C02-WBN is present on the 'ppc440' evaluation board for
boot strap purpose.
^ permalink raw reply
* Re: [PATCH 10/11] Add MPC8360EMDS board support
From: Vitaly Bordug @ 2006-09-27 11:56 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, Li Yang
In-Reply-To: <17690.7311.157219.154172@cargo.ozlabs.ibm.com>
On Wed, 27 Sep 2006 16:39:11 +1000
Paul Mackerras <paulus@samba.org> wrote:
> Li Yang writes:
>
> > +#define BCSR_PHYS_ADDR ((uint)0xf8000000)
> > +#define BCSR_SIZE ((uint)(32 * 1024))
>
> This sort of thing should really be in the device tree.
>
Just a suggestion, but for the similar aim in pq2 I have those stuff in memory node :
+memory {
+ device_type = "memory";
+ linux,phandle = <300>;
+ reg = <00000000 4000000 f4500000 00000020>;
+ };
the second pair is about bcsr and its size.
Just in case this may help (and wondering if I'm not violating something :) )
--
Sincerely,
Vitaly
^ permalink raw reply
* RE: [PATCH 10/11] Add MPC8360EMDS board support
From: Li Yang-r58472 @ 2006-09-27 12:02 UTC (permalink / raw)
To: Vitaly Bordug, Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <20060927155626.4d5ca19c@vitb.ru.mvista.com>
> -----Original Message-----
> From: Vitaly Bordug [mailto:vbordug@ru.mvista.com]
> Sent: Wednesday, September 27, 2006 7:56 PM
> To: Paul Mackerras
> Cc: Li Yang-r58472; linuxppc-dev@ozlabs.org
> Subject: Re: [PATCH 10/11] Add MPC8360EMDS board support
>=20
> On Wed, 27 Sep 2006 16:39:11 +1000
> Paul Mackerras <paulus@samba.org> wrote:
>=20
> > Li Yang writes:
> >
> > > +#define BCSR_PHYS_ADDR ((uint)0xf8000000)
> > > +#define BCSR_SIZE ((uint)(32 * 1024))
> >
> > This sort of thing should really be in the device tree.
> >
> Just a suggestion, but for the similar aim in pq2 I have those stuff
in memory node :
>=20
> +memory {
> + device_type =3D "memory";
> + linux,phandle =3D <300>;
> + reg =3D <00000000 4000000 f4500000 00000020>;
> + };
> the second pair is about bcsr and its size.
>=20
> Just in case this may help (and wondering if I'm not violating
something :) )
Well, this can make it work. But I would prefer to use a new node
because the BCSR is by no means a memory type of device. I have made my
change to use node like this:
bcsr@f8000000 {
device_type =3D "board-control";
reg =3D <f8000000 8000>;
};
- Leo
^ permalink raw reply
* [PATCH V2] Create a "wrapper" script and use it in arch/powerpc/boot
From: Paul Mackerras @ 2006-09-27 12:47 UTC (permalink / raw)
To: linuxppc-dev
This puts the knowledge of how to create various sorts of zImage
wrappers into a script called "wrapper" that could be used outside of
the kernel tree. This changes arch/powerpc/boot so it first builds
the files that the wrapper script needs, then runs it to create
whatever flavours of zImage are required.
This version does uImages as well. The zImage names are changed
slightly; zImage.pseries is the one with the PT_NOTE program header
entry added, and zImage.pmac is the one without. If the
zImage.pseries gets made, it will also get hardlinked to zImage;
otherwise, if zImage.pmac is made, it gets hardlinked to zImage.
Signed-off-by: Paul Mackerras <paulus@samba.org>
---
diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index 01667d1..a00fe72 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -20,6 +20,7 @@ CROSS32_COMPILE ?=
CROSS32CC := $(CROSS32_COMPILE)gcc
CROSS32AS := $(CROSS32_COMPILE)as
CROSS32LD := $(CROSS32_COMPILE)ld
+CROSS32AR := $(CROSS32_COMPILE)ar
CROSS32OBJCOPY := $(CROSS32_COMPILE)objcopy
ifeq ($(HAS_BIARCH),y)
@@ -28,10 +29,11 @@ CROSS32CC := $(CC) -m32
CROSS32AS := $(AS) -a32
CROSS32LD := $(LD) -m elf32ppc
CROSS32OBJCOPY := $(OBJCOPY)
+CROSS32AR := $(AR)
endif
endif
-export CROSS32CC CROSS32AS CROSS32LD CROSS32OBJCOPY
+export CROSS32CC CROSS32AS CROSS32LD CROSS32AR CROSS32OBJCOPY
KBUILD_DEFCONFIG := $(shell uname -m)_defconfig
@@ -146,7 +148,7 @@ 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 uImage
PHONY += $(BOOT_TARGETS)
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index e737741..962fa4e 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -20,33 +20,34 @@ # To make it easier to setup a cross com
# CROSS32_COMPILE is setup as a prefix just like CROSS_COMPILE
# in the toplevel makefile.
+all: $(obj)/zImage
HOSTCC := gcc
BOOTCFLAGS := $(HOSTCFLAGS) -fno-builtin -nostdinc -isystem \
$(shell $(CROSS32CC) -print-file-name=include) -fPIC
BOOTAFLAGS := -D__ASSEMBLY__ $(BOOTCFLAGS) -traditional -nostdinc
-OBJCOPYFLAGS := contents,alloc,load,readonly,data
-OBJCOPY_COFF_ARGS := -O aixcoff-rs6000 --set-start 0x500000
-OBJCOPY_MIB_ARGS := -O aixcoff-rs6000 -R .stab -R .stabstr -R .comment
+
+ifeq ($(call cc-option-yn, -fstack-protector),y)
+BOOTCFLAGS += -fno-stack-protector
+endif
+
+BOOTCFLAGS += -I$(obj) -I$(srctree)/$(obj)
zlib := inffast.c inflate.c inftrees.c
zlibheader := inffast.h inffixed.h inflate.h inftrees.h infutil.h
zliblinuxheader := zlib.h zconf.h zutil.h
-$(addprefix $(obj)/,$(zlib) main.o): $(addprefix $(obj)/,$(zliblinuxheader)) $(addprefix $(obj)/,$(zlibheader))
-#$(addprefix $(obj)/,main.o): $(addprefix $(obj)/,zlib.h)
+$(addprefix $(obj)/,$(zlib) main.o): $(addprefix $(obj)/,$(zliblinuxheader)) \
+ $(addprefix $(obj)/,$(zlibheader))
+
+src-wlib := string.S stdio.c main.c div64.S $(zlib)
+src-plat := of.c
+src-boot := crt0.S $(src-wlib) $(src-plat) empty.c
-src-boot-$(CONFIG_PPC_MULTIPLATFORM) := of.c
-src-boot := crt0.S string.S stdio.c main.c div64.S $(src-boot-y)
-src-boot += $(zlib)
src-boot := $(addprefix $(obj)/, $(src-boot))
obj-boot := $(addsuffix .o, $(basename $(src-boot)))
-
-ifeq ($(call cc-option-yn, -fstack-protector),y)
-BOOTCFLAGS += -fno-stack-protector
-endif
-
-BOOTCFLAGS += -I$(obj) -I$(srctree)/$(obj)
+obj-wlib := $(addsuffix .o, $(basename $(addprefix $(obj)/, $(src-wlib))))
+obj-plat := $(addsuffix .o, $(basename $(addprefix $(obj)/, $(src-plat))))
quiet_cmd_copy_zlib = COPY $@
cmd_copy_zlib = sed "s@__attribute_used__@@;s@<linux/\([^>]\+\).*@\"\1\"@" $< > $@
@@ -66,8 +67,14 @@ quiet_cmd_copy_zliblinuxheader = COPY
$(addprefix $(obj)/,$(zliblinuxheader)): $(obj)/%: $(srctree)/include/linux/%
$(call cmd,copy_zliblinuxheader)
-clean-files := $(zlib) $(zlibheader) $(zliblinuxheader)
+$(obj)/empty.c:
+ @touch $@
+
+$(obj)/zImage.lds $(obj)/zImage.coff.lds: $(obj)/%: $(srctree)/$(src)/%.S
+ @cp $< $@
+clean-files := $(zlib) $(zlibheader) $(zliblinuxheader) \
+ $(obj)/empty.c
quiet_cmd_bootcc = BOOTCC $@
cmd_bootcc = $(CROSS32CC) -Wp,-MD,$(depfile) $(BOOTCFLAGS) -c -o $@ $<
@@ -75,146 +82,97 @@ quiet_cmd_bootcc = BOOTCC $@
quiet_cmd_bootas = BOOTAS $@
cmd_bootas = $(CROSS32CC) -Wp,-MD,$(depfile) $(BOOTAFLAGS) -c -o $@ $<
-quiet_cmd_bootld = BOOTLD $@
- cmd_bootld = $(CROSS32LD) -T $(srctree)/$(src)/$(3) -o $@ $(2)
+quiet_cmd_bootar = BOOTAR $@
+ cmd_bootar = $(CROSS32AR) -cr $@.$$$$ $^; mv $@.$$$$ $@
$(patsubst %.c,%.o, $(filter %.c, $(src-boot))): %.o: %.c
$(call if_changed_dep,bootcc)
$(patsubst %.S,%.o, $(filter %.S, $(src-boot))): %.o: %.S
$(call if_changed_dep,bootas)
-#-----------------------------------------------------------
-# ELF sections within the zImage bootloader/wrapper
-#-----------------------------------------------------------
-required := vmlinux.strip
-initrd := initrd
+$(obj)/wrapper.a: $(obj-wlib)
+ $(call cmd,bootar)
-obj-sec = $(foreach section, $(1), $(patsubst %,$(obj)/kernel-%.o, $(section)))
-src-sec = $(foreach section, $(1), $(patsubst %,$(obj)/kernel-%.c, $(section)))
-gz-sec = $(foreach section, $(1), $(patsubst %,$(obj)/kernel-%.gz, $(section)))
+hostprogs-y := addnote addRamDisk hack-coff
-hostprogs-y := addnote addRamDisk hack-coff
+extra-y := $(obj)/crt0.o $(obj)/wrapper.a $(obj-plat) $(obj)/empty.o \
+ $(obj)/zImage.lds $(obj)/zImage.coff.lds
-targets += zImage.vmode zImage.initrd.vmode zImage zImage.initrd \
- zImage.coff zImage.initrd.coff miboot.image miboot.initrd.image \
- $(patsubst $(obj)/%,%, $(call obj-sec, $(required) $(initrd))) \
- $(patsubst $(obj)/%,%, $(call src-sec, $(required) $(initrd))) \
- $(patsubst $(obj)/%,%, $(call gz-sec, $(required) $(initrd))) \
- vmlinux.initrd dummy.o
-extra-y := initrd.o
+wrapper :=$(srctree)/$(src)/wrapper
+wrapperbits := $(extra-y) $(addprefix $(obj)/,addnote hack-coff)
-quiet_cmd_ramdisk = RAMDISK $@
- cmd_ramdisk = $(obj)/addRamDisk $(obj)/ramdisk.image.gz $< $@
+#############
+# Bits for building various flavours of zImage
-quiet_cmd_stripvm = STRIP $@
- cmd_stripvm = $(STRIP) -s -R .comment $< -o $@
+ifneq ($(CROSS32_COMPILE),)
+CROSSWRAP := -C $(CROSS32_COMPILE)
+else
+ifneq ($(CROSS_COMPILE),)
+CROSSWRAP := -C $(CROSS_COMPILE)
+endif
+endif
-vmlinux.strip: vmlinux
- $(call if_changed,stripvm)
-$(obj)/vmlinux.initrd: vmlinux.strip $(obj)/addRamDisk $(obj)/ramdisk.image.gz
- $(call if_changed,ramdisk)
+quiet_cmd_wrap = WRAP $@
+ cmd_wrap =$(wrapper) -c -o $@ -p $2 $(CROSSWRAP) vmlinux
+quiet_cmd_wrap_initrd = WRAP $@
+ cmd_wrap_initrd =$(wrapper) -c -o $@ -p $2 $(CROSSWRAP) \
+ -i $(obj)/ramdisk.image.gz vmlinux
-quiet_cmd_addsection = ADDSEC $@
- cmd_addsection = $(CROSS32OBJCOPY) $@ \
- --add-section=.kernel:$(strip $(patsubst $(obj)/kernel-%.o,%, $@))=$(patsubst %.o,%.gz, $@) \
- --set-section-flags=.kernel:$(strip $(patsubst $(obj)/kernel-%.o,%, $@))=$(OBJCOPYFLAGS)
+$(obj)/zImage.chrp: vmlinux $(wrapperbits)
+ $(call cmd,wrap,chrp)
-quiet_cmd_addnote = ADDNOTE $@
- cmd_addnote = $(obj)/addnote $@
+$(obj)/zImage.initrd.chrp: vmlinux $(wrapperbits)
+ $(call cmd,wrap_initrd,chrp)
-quiet_cmd_gen-miboot = GEN $@
- cmd_gen-miboot = $(OBJCOPY) $(OBJCOPY_MIB_ARGS) \
- --add-section=$1=$(word 2, $^) $< $@
+$(obj)/zImage.pseries: vmlinux $(wrapperbits)
+ $(call cmd,wrap,pseries)
-quiet_cmd_gencoff = COFF $@
- cmd_gencoff = $(OBJCOPY) $(OBJCOPY_COFF_ARGS) $@ && \
- $(obj)/hack-coff $@
+$(obj)/zImage.initrd.pseries: vmlinux $(wrapperbits)
+ $(call cmd,wrap_initrd,pseries)
-$(call gz-sec, $(required)): $(obj)/kernel-%.gz: %
- $(call if_changed,gzip)
+$(obj)/zImage.pmac: vmlinux $(wrapperbits)
+ $(call cmd,wrap,pmac)
-$(obj)/kernel-initrd.gz: $(obj)/ramdisk.image.gz
- cp -f $(obj)/ramdisk.image.gz $@
+$(obj)/zImage.initrd.pmac: vmlinux $(wrapperbits)
+ $(call cmd,wrap_initrd,pmac)
-$(call src-sec, $(required) $(initrd)): $(obj)/kernel-%.c: $(obj)/kernel-%.gz
- @touch $@
+$(obj)/zImage.coff: vmlinux $(wrapperbits)
+ $(call cmd,wrap,pmaccoff)
-$(call obj-sec, $(required) $(initrd)): $(obj)/kernel-%.o: $(obj)/kernel-%.c
- $(call if_changed_dep,bootcc)
- $(call cmd,addsection)
+$(obj)/zImage.initrd.coff: vmlinux $(wrapperbits)
+ $(call cmd,wrap_initrd,pmaccoff)
+
+$(obj)/zImage.miboot: vmlinux $(wrapperbits)
+ $(call cmd,wrap,miboot)
-$(obj)/zImage.vmode $(obj)/zImage.coff: obj-boot += $(call obj-sec, $(required))
-$(obj)/zImage.vmode: $(call obj-sec, $(required)) $(obj-boot) $(srctree)/$(src)/zImage.lds
- $(call cmd,bootld,$(obj-boot),zImage.lds)
+$(obj)/zImage.initrd.miboot: vmlinux $(wrapperbits)
+ $(call cmd,wrap_initrd,miboot)
-$(obj)/zImage.initrd.vmode $(obj)/zImage.initrd.coff: obj-boot += $(call obj-sec, $(required) $(initrd))
-$(obj)/zImage.initrd.vmode: $(call obj-sec, $(required) $(initrd)) $(obj-boot) $(srctree)/$(src)/zImage.lds
- $(call cmd,bootld,$(obj-boot),zImage.lds)
+$(obj)/uImage: vmlinux $(wrapperbits)
+ $(call cmd,wrap,uboot)
+
+image-$(CONFIG_PPC_PSERIES) += zImage.pseries
+image-$(CONFIG_PPC_MAPLE) += zImage.pseries
+image-$(CONFIG_PPC_CELL) += zImage.pseries
+image-$(CONFIG_PPC_CHRP) += zImage.chrp
+image-$(CONFIG_PPC_PMAC) += zImage.pmac
+image-$(CONFIG_DEFAULT_UIMAGE) += uImage
# For 32-bit powermacs, build the COFF and miboot images
# as well as the ELF images.
-coffimage-$(CONFIG_PPC_PMAC)-$(CONFIG_PPC32) := $(obj)/zImage.coff
-coffrdimg-$(CONFIG_PPC_PMAC)-$(CONFIG_PPC32) := $(obj)/zImage.initrd.coff
-mibootimg-$(CONFIG_PPC_PMAC)-$(CONFIG_PPC32) := $(obj)/miboot.image
-mibrdimg-$(CONFIG_PPC_PMAC)-$(CONFIG_PPC32) := $(obj)/miboot.initrd.image
-
-$(obj)/zImage: $(obj)/zImage.vmode $(obj)/addnote $(coffimage-y-y) \
- $(mibootimg-y-y)
- @cp -f $< $@
- $(call if_changed,addnote)
-
-$(obj)/zImage.initrd: $(obj)/zImage.initrd.vmode $(obj)/addnote \
- $(coffrdimg-y-y) $(mibrdimg-y-y)
- @cp -f $< $@
- $(call if_changed,addnote)
-
-$(obj)/zImage.coff: $(call obj-sec, $(required)) $(obj-boot) \
- $(srctree)/$(src)/zImage.coff.lds $(obj)/hack-coff
- $(call cmd,bootld,$(obj-boot),zImage.coff.lds)
- $(call cmd,gencoff)
-
-$(obj)/zImage.initrd.coff: $(call obj-sec, $(required) $(initrd)) $(obj-boot) \
- $(srctree)/$(src)/zImage.coff.lds $(obj)/hack-coff
- $(call cmd,bootld,$(obj-boot),zImage.coff.lds)
- $(call cmd,gencoff)
-
-$(obj)/miboot.image: $(obj)/dummy.o $(obj)/vmlinux.gz
- $(call cmd,gen-miboot,image)
-
-$(obj)/miboot.initrd.image: $(obj)/miboot.image $(images)/ramdisk.image.gz
- $(call cmd,gen-miboot,initrd)
-
-#-----------------------------------------------------------
-# build u-boot images
-#-----------------------------------------------------------
-quiet_cmd_mygzip = GZIP $@
-cmd_mygzip = gzip -f -9 < $< > $@.$$$$ && mv $@.$$$$ $@
-
-quiet_cmd_objbin = OBJCOPY $@
- cmd_objbin = $(OBJCOPY) -O binary $< $@
-
-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 $< $@
-
-MKIMAGE := $(srctree)/scripts/mkuboot.sh
-targets += uImage
-extra-y += vmlinux.bin vmlinux.gz
-
-$(obj)/vmlinux.bin: vmlinux FORCE
- $(call if_changed,objbin)
-
-$(obj)/vmlinux.gz: $(obj)/vmlinux.bin FORCE
- $(call if_changed,mygzip)
-
-$(obj)/uImage: $(obj)/vmlinux.gz
- $(Q)rm -f $@
- $(call cmd,uimage)
- @echo -n ' Image: $@ '
- @if [ -f $@ ]; then echo 'is ready' ; else echo 'not made'; fi
-
-install: $(CONFIGURE) $(BOOTIMAGE)
- sh -x $(srctree)/$(src)/install.sh "$(KERNELRELEASE)" vmlinux System.map "$(INSTALL_PATH)" "$(BOOTIMAGE)"
-
-clean-files += $(addprefix $(objtree)/, $(obj-boot) vmlinux.strip)
+ifeq ($(CONFIG_PPC32),y)
+image-$(CONFIG_PPC_PMAC) += zImage.coff zImage.miboot
+endif
+
+initrd-y := $(patsubst zImage%, zImage.initrd%, $(image-y))
+
+$(obj)/zImage: $(addprefix $(obj)/, $(image-y))
+ @rm -f $@; ln $< $@
+$(obj)/zImage.initrd: $(addprefix $(obj)/, $(initrd-y))
+ @rm -f $@; ln $< $@
+
+install: $(CONFIGURE) $(image-y)
+ sh -x $(srctree)/$(src)/install.sh "$(KERNELRELEASE)" vmlinux System.map "$(INSTALL_PATH)" $<
+
+clean-files += $(addprefix $(objtree)/, $(obj-boot) vmlinux.strip.gz)
+clean-files += $(addprefix $(objtree)/, $(obj-boot) vmlinux.bin.gz)
diff --git a/arch/powerpc/boot/wrapper b/arch/powerpc/boot/wrapper
new file mode 100755
index 0000000..eab7318
--- /dev/null
+++ b/arch/powerpc/boot/wrapper
@@ -0,0 +1,204 @@
+#!/bin/sh
+
+# Copyright (C) 2006 Paul Mackerras, IBM Corporation <paulus@samba.org>
+# This program may be used under the terms of version 2 of the GNU
+# General Public License.
+
+# This script takes a kernel binary and optionally an initrd image
+# and/or a device-tree blob, and creates a bootable zImage for a
+# given platform.
+
+# Options:
+# -o zImage specify output file
+# -p platform specify platform (links in $platform.o)
+# -i initrd specify initrd file
+# -d devtree specify device-tree blob
+# -s tree.dts specify device-tree source file (needs dtc installed)
+# -c cache $kernel.strip.gz (use if present & newer, else make)
+# -C prefix specify command prefix for cross-building tools
+# (strip, objcopy, ld)
+# -D dir specify directory containing data files used by script
+# (default ./arch/powerpc/boot)
+# -W dir specify working directory for temporary files (default .)
+
+# defaults
+kernel=
+ofile=zImage
+platform=of
+initrd=
+dtb=
+dts=
+cacheit=
+
+# cross-compilation prefix
+CROSS=
+
+# directory for object and other files used by this script
+object=arch/powerpc/boot
+
+# directory for working files
+tmpdir=.
+
+usage() {
+ echo 'Usage: wrapper [-o output] [-p platform] [-i initrd]' >&2
+ echo ' [-d devtree] [-s tree.dts] [-c] [-C cross-prefix]' >&2
+ echo ' [-D datadir] [-W workingdir] [vmlinux]' >&2
+ exit 1
+}
+
+while [ "$#" -gt 0 ]; do
+ case "$1" in
+ -o)
+ shift
+ [ "$#" -gt 0 ] || usage
+ ofile="$1"
+ ;;
+ -p)
+ shift
+ [ "$#" -gt 0 ] || usage
+ platform="$1"
+ ;;
+ -i)
+ shift
+ [ "$#" -gt 0 ] || usage
+ initrd="$1"
+ ;;
+ -d)
+ shift
+ [ "$#" -gt 0 ] || usage
+ dtb="$1"
+ ;;
+ -s)
+ shift
+ [ "$#" -gt 0 ] || usage
+ dts="$1"
+ ;;
+ -c)
+ cacheit=y
+ ;;
+ -C)
+ shift
+ [ "$#" -gt 0 ] || usage
+ CROSS="$1"
+ ;;
+ -D)
+ shift
+ [ "$#" -gt 0 ] || usage
+ object="$1"
+ ;;
+ -W)
+ shift
+ [ "$#" -gt 0 ] || usage
+ tmpdir="$1"
+ ;;
+ -?)
+ usage
+ ;;
+ *)
+ [ -z "$kernel" ] || usage
+ kernel="$1"
+ ;;
+ esac
+ shift
+done
+
+if [ -n "$dts" ]; then
+ if [ -z "$dtb" ]; then
+ dtb="$platform.dtb"
+ fi
+ dtc -O dtb -o "$dtb" -b 0 -V 16 "$dts" || exit 1
+fi
+
+if [ -z "$kernel" ]; then
+ kernel=vmlinux
+fi
+
+platformo=$object/"$platform".o
+lds=$object/zImage.lds
+ext=strip
+objflags=-S
+tmp=$tmpdir/zImage.$$.o
+ksection=.kernel:vmlinux.strip
+isection=.kernel:initrd
+
+case "$platform" in
+pmac|pseries|chrp)
+ platformo=$object/of.o
+ ;;
+pmaccoff)
+ platformo=$object/of.o
+ lds=$object/zImage.coff.lds
+ ;;
+miboot|uboot)
+ # miboot and U-boot want just the bare bits, not an ELF binary
+ ext=bin
+ objflags="-O binary"
+ tmp="$ofile"
+ ksection=image
+ isection=initrd
+ ;;
+esac
+
+vmz="$tmpdir/`basename \"$kernel\"`.$ext"
+if [ -z "$cacheit" -o ! -f "$vmz.gz" -o "$vmz.gz" -ot "$kernel" ]; then
+ ${CROSS}objcopy $objflags "$kernel" "$vmz.$$"
+ gzip -f -9 "$vmz.$$"
+ if [ -n "$cacheit" ]; then
+ mv -f "$vmz.$$.gz" "$vmz.gz"
+ else
+ vmz="$vmz.$$"
+ fi
+fi
+
+case "$platform" in
+uboot)
+ rm -f "$ofile"
+ version=`${CROSS}strings "$kernel" | grep '^Linux version [-0-9.]' | \
+ cut -d' ' -f3`
+ if [ -n "$version" ]; then
+ version="-n Linux-$version"
+ fi
+ mkimage -A ppc -O linux -T kernel -C gzip -a 00000000 -e 00000000 \
+ $version -d "$vmz.gz" "$ofile"
+ if [ -z "$cacheit" ]; then
+ rm -f $vmz.gz
+ fi
+ exit 0
+ ;;
+esac
+
+addsec() {
+ ${CROSS}objcopy $4 $1 \
+ --add-section=$3="$2" \
+ --set-section-flags=$3=contents,alloc,load,readonly,data
+}
+
+addsec $tmp "$vmz.gz" $ksection $object/empty.o
+if [ -z "$cacheit" ]; then
+ rm -f "$vmz.gz"
+fi
+
+if [ -n "$initrd" ]; then
+ addsec $tmp "$initrd" initrd
+fi
+
+if [ -n "$dtb" ]; then
+ addsec $tmp "$dtb" dtb
+fi
+
+if [ "$platform" != "miboot" ]; then
+ ${CROSS}ld -m elf32ppc -T $lds -o "$ofile" \
+ $object/crt0.o $platformo $tmp $object/wrapper.a
+ rm $tmp
+fi
+
+# post-processing needed for some platforms
+case "$platform" in
+pseries|chrp)
+ $object/addnote "$ofile"
+ ;;
+pmaccoff)
+ ${CROSS}objcopy -O aixcoff-rs6000 --set-start 0x500000 "$ofile"
+ $object/hack-coff "$ofile"
+ ;;
+esac
diff --git a/arch/powerpc/boot/zImage.coff.lds b/arch/powerpc/boot/zImage.coff.lds
deleted file mode 100644
index 6016251..0000000
--- a/arch/powerpc/boot/zImage.coff.lds
+++ /dev/null
@@ -1,46 +0,0 @@
-OUTPUT_ARCH(powerpc:common)
-ENTRY(_start)
-SECTIONS
-{
- . = (5*1024*1024);
- _start = .;
- .text :
- {
- *(.text)
- *(.fixup)
- }
- _etext = .;
- . = ALIGN(4096);
- .data :
- {
- *(.rodata*)
- *(.data*)
- *(.sdata*)
- __got2_start = .;
- *(.got2)
- __got2_end = .;
-
- _vmlinux_start = .;
- *(.kernel:vmlinux.strip)
- _vmlinux_end = .;
-
- _initrd_start = .;
- *(.kernel:initrd)
- _initrd_end = .;
- }
-
- . = ALIGN(4096);
- _edata = .;
- __bss_start = .;
- .bss :
- {
- *(.sbss)
- *(.bss)
- }
- _end = . ;
-
- /DISCARD/ :
- {
- *(.comment)
- }
-}
diff --git a/arch/powerpc/boot/zImage.coff.lds.S b/arch/powerpc/boot/zImage.coff.lds.S
new file mode 100644
index 0000000..6016251
--- /dev/null
+++ b/arch/powerpc/boot/zImage.coff.lds.S
@@ -0,0 +1,46 @@
+OUTPUT_ARCH(powerpc:common)
+ENTRY(_start)
+SECTIONS
+{
+ . = (5*1024*1024);
+ _start = .;
+ .text :
+ {
+ *(.text)
+ *(.fixup)
+ }
+ _etext = .;
+ . = ALIGN(4096);
+ .data :
+ {
+ *(.rodata*)
+ *(.data*)
+ *(.sdata*)
+ __got2_start = .;
+ *(.got2)
+ __got2_end = .;
+
+ _vmlinux_start = .;
+ *(.kernel:vmlinux.strip)
+ _vmlinux_end = .;
+
+ _initrd_start = .;
+ *(.kernel:initrd)
+ _initrd_end = .;
+ }
+
+ . = ALIGN(4096);
+ _edata = .;
+ __bss_start = .;
+ .bss :
+ {
+ *(.sbss)
+ *(.bss)
+ }
+ _end = . ;
+
+ /DISCARD/ :
+ {
+ *(.comment)
+ }
+}
diff --git a/arch/powerpc/boot/zImage.lds b/arch/powerpc/boot/zImage.lds
deleted file mode 100644
index 4b6bb3f..0000000
--- a/arch/powerpc/boot/zImage.lds
+++ /dev/null
@@ -1,46 +0,0 @@
-OUTPUT_ARCH(powerpc:common)
-ENTRY(_zimage_start)
-SECTIONS
-{
- . = (4*1024*1024);
- _start = .;
- .text :
- {
- *(.text)
- *(.fixup)
- }
- _etext = .;
- . = ALIGN(4096);
- .data :
- {
- *(.rodata*)
- *(.data*)
- *(.sdata*)
- __got2_start = .;
- *(.got2)
- __got2_end = .;
- }
-
- . = ALIGN(4096);
- _vmlinux_start = .;
- .kernel:vmlinux.strip : { *(.kernel:vmlinux.strip) }
- _vmlinux_end = .;
-
- . = ALIGN(4096);
- _initrd_start = .;
- .kernel:initrd : { *(.kernel:initrd) }
- _initrd_end = .;
-
- . = ALIGN(4096);
- _edata = .;
-
- . = ALIGN(4096);
- __bss_start = .;
- .bss :
- {
- *(.sbss)
- *(.bss)
- }
- . = ALIGN(4096);
- _end = . ;
-}
diff --git a/arch/powerpc/boot/zImage.lds.S b/arch/powerpc/boot/zImage.lds.S
new file mode 100644
index 0000000..4b6bb3f
--- /dev/null
+++ b/arch/powerpc/boot/zImage.lds.S
@@ -0,0 +1,46 @@
+OUTPUT_ARCH(powerpc:common)
+ENTRY(_zimage_start)
+SECTIONS
+{
+ . = (4*1024*1024);
+ _start = .;
+ .text :
+ {
+ *(.text)
+ *(.fixup)
+ }
+ _etext = .;
+ . = ALIGN(4096);
+ .data :
+ {
+ *(.rodata*)
+ *(.data*)
+ *(.sdata*)
+ __got2_start = .;
+ *(.got2)
+ __got2_end = .;
+ }
+
+ . = ALIGN(4096);
+ _vmlinux_start = .;
+ .kernel:vmlinux.strip : { *(.kernel:vmlinux.strip) }
+ _vmlinux_end = .;
+
+ . = ALIGN(4096);
+ _initrd_start = .;
+ .kernel:initrd : { *(.kernel:initrd) }
+ _initrd_end = .;
+
+ . = ALIGN(4096);
+ _edata = .;
+
+ . = ALIGN(4096);
+ __bss_start = .;
+ .bss :
+ {
+ *(.sbss)
+ *(.bss)
+ }
+ . = ALIGN(4096);
+ _end = . ;
+}
^ permalink raw reply related
* Re: [PATCH] Use check_legacy_ioport() for ISAPnP
From: David Woodhouse @ 2006-09-27 12:49 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev, paulus
In-Reply-To: <20060927081838.GA5984@aepfle.de>
On Wed, 2006-09-27 at 10:18 +0200, Olaf Hering wrote:
> Isnt that fixed by my other patch which was merged into -mm today?
Hm, wasn't aware of that.
/me looks...
No, your patch seems to change pnpbios, not isapnp. Which is odd, since
pnpbios is x86-only anyway.
And did you fix the case of PCI parallel ports? We only want to do the
check_legacy_ioport() thing for the 'default' built-in ports, not for
all ports.
--
dwmw2
^ permalink raw reply
* Re: [PATCH 10/11] Add MPC8360EMDS board support
From: Vitaly Bordug @ 2006-09-27 12:55 UTC (permalink / raw)
To: Li Yang-r58472; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <4879B0C6C249214CBE7AB04453F84E4D19D865@zch01exm20.fsl.freescale.net>
On Wed, 27 Sep 2006 20:02:56 +0800
"Li Yang-r58472" <LeoLi@freescale.com> wrote:
> > -----Original Message-----
> > From: Vitaly Bordug [mailto:vbordug@ru.mvista.com]
> > Sent: Wednesday, September 27, 2006 7:56 PM
> > To: Paul Mackerras
> > Cc: Li Yang-r58472; linuxppc-dev@ozlabs.org
> > Subject: Re: [PATCH 10/11] Add MPC8360EMDS board support
> >
> > On Wed, 27 Sep 2006 16:39:11 +1000
> > Paul Mackerras <paulus@samba.org> wrote:
> >
> > > Li Yang writes:
> > >
> > > > +#define BCSR_PHYS_ADDR ((uint)0xf8000000)
> > > > +#define BCSR_SIZE ((uint)(32 * 1024))
> > >
> > > This sort of thing should really be in the device tree.
> > >
> > Just a suggestion, but for the similar aim in pq2 I have those stuff
> in memory node :
> >
> > +memory {
> > + device_type = "memory";
> > + linux,phandle = <300>;
> > + reg = <00000000 4000000 f4500000 00000020>;
> > + };
> > the second pair is about bcsr and its size.
> >
> > Just in case this may help (and wondering if I'm not violating
> something :) )
>
> Well, this can make it work. But I would prefer to use a new node
> because the BCSR is by no means a memory type of device. I have made my
> change to use node like this:
>
> bcsr@f8000000 {
> device_type = "board-control";
> reg = <f8000000 8000>;
> };
>
I though about that approach, but saw somewhere a reference that we should not summon new node types without utter necessity, and utilized memory because bcsr is memory-mapped stuff. I can hardly imagine bcsr as a device (which would require respective spec inclusion btw).
hence let's open a discussion what others think about that. The problem seems common (and for some boards
is called somewhat else apparently), but at this point we should come to some conclusion, document it, and use it.
--
Sincerely,
Vitaly
^ permalink raw reply
* Re: [PATCH] Use check_legacy_ioport() for ISAPnP
From: Olaf Hering @ 2006-09-27 13:05 UTC (permalink / raw)
To: David Woodhouse; +Cc: linuxppc-dev, paulus
In-Reply-To: <1159361385.3309.118.camel@pmac.infradead.org>
On Wed, Sep 27, David Woodhouse wrote:
> And did you fix the case of PCI parallel ports? We only want to do the
> check_legacy_ioport() thing for the 'default' built-in ports, not for
> all ports.
I have to check if my multiport IO card still works, but I'm sure it
will.
^ permalink raw reply
* RE: [PATCH 10/11] Add MPC8360EMDS board support
From: Li Yang-r58472 @ 2006-09-27 13:20 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20060927165556.04c8d5d7@vitb.ru.mvista.com>
> -----Original Message-----
> From: Vitaly Bordug [mailto:vbordug@ru.mvista.com]
> Sent: Wednesday, September 27, 2006 8:56 PM
> To: Li Yang-r58472
> Cc: Paul Mackerras; linuxppc-dev@ozlabs.org
> Subject: Re: [PATCH 10/11] Add MPC8360EMDS board support
>=20
> On Wed, 27 Sep 2006 20:02:56 +0800
> "Li Yang-r58472" <LeoLi@freescale.com> wrote:
>=20
> > > -----Original Message-----
> > > From: Vitaly Bordug [mailto:vbordug@ru.mvista.com]
> > > Sent: Wednesday, September 27, 2006 7:56 PM
> > > To: Paul Mackerras
> > > Cc: Li Yang-r58472; linuxppc-dev@ozlabs.org
> > > Subject: Re: [PATCH 10/11] Add MPC8360EMDS board support
> > >
> > > On Wed, 27 Sep 2006 16:39:11 +1000
> > > Paul Mackerras <paulus@samba.org> wrote:
> > >
> > > > Li Yang writes:
> > > >
> > > > > +#define BCSR_PHYS_ADDR ((uint)0xf8000000)
> > > > > +#define BCSR_SIZE ((uint)(32 * 1024))
> > > >
> > > > This sort of thing should really be in the device tree.
> > > >
> > > Just a suggestion, but for the similar aim in pq2 I have those
stuff
> > in memory node :
> > >
> > > +memory {
> > > + device_type =3D "memory";
> > > + linux,phandle =3D <300>;
> > > + reg =3D <00000000 4000000 f4500000 00000020>;
> > > + };
> > > the second pair is about bcsr and its size.
> > >
> > > Just in case this may help (and wondering if I'm not violating
> > something :) )
> >
> > Well, this can make it work. But I would prefer to use a new node
> > because the BCSR is by no means a memory type of device. I have
made my
> > change to use node like this:
> >
> > bcsr@f8000000 {
> > device_type =3D "board-control";
> > reg =3D <f8000000 8000>;
> > };
> >
>=20
> I though about that approach, but saw somewhere a reference that we
should not summon
> new node types without utter necessity, and utilized memory because
bcsr is
> memory-mapped stuff. I can hardly imagine bcsr as a device (which
would require
> respective spec inclusion btw).
Well I didn't see such a guideline. However BCSR is truly a device like
any other peripherals on board. Usually it is an FPGA on local bus to
control the board.
>=20
> hence let's open a discussion what others think about that. The
problem seems common
> (and for some boards
> is called somewhat else apparently), but at this point we should come
to some
> conclusion, document it, and use it.
Agreed. As we are adding more devices to the device tree, we should
also have a guideline clearly stated for adding new nodes. =20
I'm adding MURAM as a new node under QE bus. Please comment.
muram@10000 {
device_type =3D "memory";
ranges =3D <0 00010000 0000c000>;
data-only@0{
reg =3D <0 c000>;
};
};
- Leo
^ permalink raw reply
* flash operations in linux on ML403
From: Ming Liu @ 2006-09-27 13:24 UTC (permalink / raw)
To: linuxppc-embedded
Dear all,
Can anyone tell me, how to include the driver for flash chips on ML403
board and make the flash chip a visible device which could be written or
read in Linux 2.6? I notice that there is a item called "MTD" in the
"device driver" in the kernel menuconfig. Is that the driver for the flash
chip? And also how to make it visiable in /dev/ ? Thanks in advance for
your telling.
Regards
Ming
_________________________________________________________________
与联机的朋友进行交流，请使用 MSN Messenger: http://messenger.msn.com/cn
^ permalink raw reply
* Re: [PATCH 10/11] Add MPC8360EMDS board support
From: Ben Warren @ 2006-09-27 13:09 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20060927165556.04c8d5d7@vitb.ru.mvista.com>
On Wed, 2006-09-27 at 16:55 +0400, Vitaly Bordug wrote:
>
> I though about that approach, but saw somewhere a reference that we should not summon new node types without utter necessity, and utilized memory because bcsr is memory-mapped stuff. I can hardly imagine bcsr as a device (which would require respective spec inclusion btw).
>
> hence let's open a discussion what others think about that. The problem seems common (and for some boards
> is called somewhat else apparently), but at this point we should come to some conclusion, document it, and use it.
>
Since "memory" is not quite specific enough, but "board-control" is a
little bit Freescale and application-centric, how about
"memmapped-device", or something like that. This could encompass FPGAs,
ASICs, CPLDs or anything else that is memory mapped. Many custom
embedded boards have lots of such devices and could benefit from this
approach.
regards,
Ben
^ permalink raw reply
* Re: [PATCH 10/11] Add MPC8360EMDS board support
From: Kumar Gala @ 2006-09-27 13:33 UTC (permalink / raw)
To: Li Yang-r58472; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <4879B0C6C249214CBE7AB04453F84E4D19D866@zch01exm20.fsl.freescale.net>
>>>> +memory {
>>>> + device_type = "memory";
>>>> + linux,phandle = <300>;
>>>> + reg = <00000000 4000000 f4500000 00000020>;
>>>> + };
>>>> the second pair is about bcsr and its size.
>>>>
>>>> Just in case this may help (and wondering if I'm not violating
>>> something :) )
>>>
>>> Well, this can make it work. But I would prefer to use a new node
>>> because the BCSR is by no means a memory type of device. I have
> made my
>>> change to use node like this:
>>>
>>> bcsr@f8000000 {
>>> device_type = "board-control";
>>> reg = <f8000000 8000>;
>>> };
>>>
>>
>> I though about that approach, but saw somewhere a reference that we
> should not summon
>> new node types without utter necessity, and utilized memory because
> bcsr is
>> memory-mapped stuff. I can hardly imagine bcsr as a device (which
> would require
>> respective spec inclusion btw).
>
> Well I didn't see such a guideline. However BCSR is truly a device
> like
> any other peripherals on board. Usually it is an FPGA on local bus to
> control the board.
Agree that a new node is better, calling it memory isn't right.
However, I'm not sure this really needs a node in the device tree.
The BCSR isn't really the same from board to board last time I
checked. I'd be interested in Paul's thinking about why it should be
in the tree.
>> hence let's open a discussion what others think about that. The
> problem seems common
>> (and for some boards
>> is called somewhat else apparently), but at this point we should come
> to some
>> conclusion, document it, and use it.
>
> Agreed. As we are adding more devices to the device tree, we should
> also have a guideline clearly stated for adding new nodes.
>
> I'm adding MURAM as a new node under QE bus. Please comment.
> muram@10000 {
> device_type = "memory";
> ranges = <0 00010000 0000c000>;
>
> data-only@0{
> reg = <0 c000>;
> };
> };
What was the need for this?
- kumar
^ permalink raw reply
* RE: [PATCH 10/11] Add MPC8360EMDS board support
From: Joakim Tjernlund @ 2006-09-27 13:54 UTC (permalink / raw)
To: Li Yang-r58472, Vitaly Bordug; +Cc: linuxppc-dev, Paul Mackerras
>=20
> I'm adding MURAM as a new node under QE bus. Please comment.
> muram@10000 {
> device_type =3D "memory";
> ranges =3D <0 00010000 0000c000>;
>=20
> data-only@0{
> reg =3D <0 c000>;
> };
> };
while you are at it, I think you should add support for the ASSIGN PAGE
command that can relocate
the parameter RAM used by UCC, SPI etc. As it is now the third(8400) and
fourth(100) value
in reg below is ignored.
ucc@2000 {
device_type =3D "network";
compatible =3D "ucc_geth";
model =3D "UCC";
device-id =3D <1>;
reg =3D <2000 200 8400 100>;
MPC832x only has 16KB of parameter RAM and needs to move this to lower
addresses.=20
^ permalink raw reply
* RE: Need help to write I2C EEPROM device driver
From: Sachin Rane @ 2006-09-27 14:11 UTC (permalink / raw)
To: Matthias Fuchs, linuxppc-embedded
In-Reply-To: <200609271221.54878.matthias.fuchs@esd-electronics.com>
[-- Attachment #1: Type: text/plain, Size: 1286 bytes --]
Hi Matthias,
Thanks for reply.
To access EEPROM using /dev/i2c-<x>, which drivers I need to load?
Please confirm that I need to load following drivers:
1. i2c-core.ko (Core Driver)
2. i2c-ibm-iic.ko (Bus Driver)
3. i2c-dev.ko (Dev Interface driver)
Do I need to load 'eeprom.ko'?
Because in one of the mail from the mailing list, it was mentioned that I should not load ''eeprom.ko" to access the chip using 'dev' interface.
Thanks and Regards,
Sachin Rane
________________________________
From: Matthias Fuchs [mailto:matthias.fuchs@esd-electronics.com]
Sent: Wed 9/27/2006 6:21 AM
To: linuxppc-embedded@ozlabs.org
Cc: Sachin Rane
Subject: Re: Need help to write I2C EEPROM device driver
Hi Sachin,
there is already a driver for this part in the kernel
(drivers/i2c/chips/eeprom.c).
BTW: to do some simple reads and writes to an I2C EEPROM it is very simple to
access the EEPROM via read/write/ioctl through /dev/i2c-<x>. No driver - only
userland code.
Matthias
On Tuesday 26 September 2006 16:34, Sachin Rane wrote:
> Hi,
>
> I am looking for an information to write a device driver to access EEPROM IC
M24C02-WBN6.
> The EEPROM IC M24C02-WBN is present on the 'ppc440' evaluation board for
boot strap purpose.
[-- Attachment #2: Type: text/html, Size: 2589 bytes --]
^ permalink raw reply
* Re: [PATCH 10/11] Add MPC8360EMDS board support
From: Jon Loeliger @ 2006-09-27 14:14 UTC (permalink / raw)
To: Li Yang-r58472; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <4879B0C6C249214CBE7AB04453F84E4D19D866@zch01exm20.fsl.freescale.net>
So, like, the other day "Li Yang-r58472" mumbled:
> Agreed. As we are adding more devices to the device tree, we should
> also have a guideline clearly stated for adding new nodes.
>
> I'm adding MURAM as a new node under QE bus. Please comment.
> muram@10000 {
> device_type = "memory";
> ranges = <0 00010000 0000c000>;
>
> data-only@0{
> reg = <0 c000>;
> };
> };
>
> - Leo
So, does it make sense for this node to participate in the early scan
of memory available during the early_init_dt_scan_memory() pass?
Out of curiosity, is "data-only" a standard thing, or did you make
that up too? What's it mean?
And your patch for this new node introduction will contain
proposed additions to the QE section of the booting-without-of
documentation, right?
Thanks,
jdl
^ permalink raw reply
* Re: [PATCH 10/11] Add MPC8360EMDS board support
From: Dan Malek @ 2006-09-27 14:42 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20060927165556.04c8d5d7@vitb.ru.mvista.com>
On Sep 27, 2006, at 8:55 AM, Vitaly Bordug wrote:
> hence let's open a discussion what others think about that. The
> problem seems common (and for some boards
> is called somewhat else apparently), but at this point we should
> come to some conclusion, document it, and use it.
Well, I haven't voiced my opinion lately.......... :-)
I think this is totally out of control. I don't even know what
we are trying to create here any more. We took a reasonable
idea to express some configuration flexibility and are running
off into into some world that we think we need to create
something infinitely flexible that anyone can use for anything
they wish. I could expect this from a university research
project, but not from seasoned developers that are trying
to create products where only a few real configuration
combinations make sense.
Since BCSRs are board specific, does anyone remember
the day when a simple #define, ioremap, and a few lines
of code in the board setup file was all that was needed? :-)
What wrong with still doing that? It seems everyone is
obsessed with device tree syntax and forget that a
few lines of code may still be a reasonable solution.
I still think an embedded_feature_call() support in a
board port would be the best solution to many of these
complex things we are trying to define in this device
tree information. In the places where we need some
kind of board specific support, like hardware set up for
some peripheral, just do the feature_call, passing enough
information to indicate what is needed, and let the
board support do what is necessary. This could be
setting bits in a BCSR, setting up the processor IO
ports, enabling power to external logic, etc. This has
been proven to work well on the PMAC, just extend it
to be used on embedded boards.
Thanks.
-- Dan
^ permalink raw reply
* Re: How to move from /ppc/ to /powerpc/
From: Fredrik Roubert @ 2006-09-27 14:49 UTC (permalink / raw)
To: Matthew McClintock; +Cc: linuxppc-embedded
In-Reply-To: <1159210763.5485.10.camel@localhost>
[-- Attachment #1: Type: text/plain, Size: 827 bytes --]
On Mon 25 Sep 20:59 CEST 2006, Matthew McClintock wrote:
> Can you verify the flat device tree passed to the kernel is correct?
> Specifically these properties:
>
> timebase-frequency = <0>; // from bootloader
> bus-frequency = <0>; // from bootloader
> clock-frequency = <0>; // from bootloader
Right on target! These values were not set up correctly, and after
fixing that I can now boot an unmodified powerpc 2.6.18 kernel.
Thank you so very much!
Are your flat device tree patches going to be included in the mainline
U-Boot in the future, or is it likely that some other method will be
used?
Cheers // Fredrik Roubert
--
Visserij 192 | +32 473 344527 / +46 708 776974
BE-9000 Gent | http://www.df.lth.se/~roubert/
[-- Attachment #2: Type: application/pgp-signature, Size: 303 bytes --]
^ permalink raw reply
* Re: Need help to write I2C EEPROM device driver
From: Matthias Fuchs @ 2006-09-27 14:51 UTC (permalink / raw)
To: Sachin Rane; +Cc: linuxppc-embedded
In-Reply-To: <8584FDC94AFF7640B17B8A89B23B19B34F6593@sbsserver.AlphionCorp.local>
On Wednesday 27 September 2006 16:11, Sachin Rane wrote:
> To access EEPROM using /dev/i2c-<x>, which drivers I need to load?
>
> Please confirm that I need to load following drivers:
> 1. i2c-core.ko (Core Driver)
> 2. i2c-ibm-iic.ko (Bus Driver)
> 3. i2c-dev.ko (Dev Interface driver)
That looks good.
> Do I need to load 'eeprom.ko'?
No.
> Because in one of the mail from the mailing list, it was mentioned that I
should not load ''eeprom.ko" to access the chip using 'dev' interface.
Either use access via /dev/i2c-x or via eeprom driver. I haven't used the
later one so far. Using both at the same time is probably not possible.
Matthias
>
> Thanks and Regards,
> Sachin Rane
>
> ________________________________
>
> From: Matthias Fuchs [mailto:matthias.fuchs@esd-electronics.com]
> Sent: Wed 9/27/2006 6:21 AM
> To: linuxppc-embedded@ozlabs.org
> Cc: Sachin Rane
> Subject: Re: Need help to write I2C EEPROM device driver
>
>
>
> Hi Sachin,
>
> there is already a driver for this part in the kernel
> (drivers/i2c/chips/eeprom.c).
>
> BTW: to do some simple reads and writes to an I2C EEPROM it is very simple
to
> access the EEPROM via read/write/ioctl through /dev/i2c-<x>. No driver -
only
> userland code.
>
> Matthias
>
>
> On Tuesday 26 September 2006 16:34, Sachin Rane wrote:
> > Hi,
> >
> > I am looking for an information to write a device driver to access EEPROM
IC
> M24C02-WBN6.
> > The EEPROM IC M24C02-WBN is present on the 'ppc440' evaluation board for
> boot strap purpose.
>
>
>
^ permalink raw reply
* Re: [PATCH 10/11] Add MPC8360EMDS board support
From: Sergei Shtylyov @ 2006-09-27 14:57 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20060927165556.04c8d5d7@vitb.ru.mvista.com>
Hello.
Vitaly Bordug wrote:
>>>>>+#define BCSR_PHYS_ADDR ((uint)0xf8000000)
>>>>>+#define BCSR_SIZE ((uint)(32 * 1024))
>>>>This sort of thing should really be in the device tree.
>>>Just a suggestion, but for the similar aim in pq2 I have those stuff
>>in memory node :
>>>+memory {
>>>+ device_type = "memory";
>>>+ linux,phandle = <300>;
>>>+ reg = <00000000 4000000 f4500000 00000020>;
>>>+ };
>>>the second pair is about bcsr and its size.
>>>Just in case this may help (and wondering if I'm not violating
>>something :) )
>>Well, this can make it work. But I would prefer to use a new node
>>because the BCSR is by no means a memory type of device. I have made my
>>change to use node like this:
>> bcsr@f8000000 {
>> device_type = "board-control";
>> reg = <f8000000 8000>;
>> };
> I though about that approach, but saw somewhere a reference that we should not summon new node types without utter necessity, and utilized memory because bcsr is memory-mapped stuff.
You might have utilized "memory" even for the Ethernet controllers guided
by such logic. Of course, that was a wrong criterion -- "memory" is for RAM,
otherwise you'd be fooling the kernel device tree scanner which looks for the
"memory" nodes.
> I can hardly imagine bcsr as a device (which would require respective spec inclusion btw).
And this is hardly a memory, neverthless.
WBR, Sergei
^ permalink raw reply
* Re: How to move from /ppc/ to /powerpc/
From: Fredrik Roubert @ 2006-09-27 15:51 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20060913132817.GD18263@igloo.df.lth.se>
[-- Attachment #1: Type: text/plain, Size: 645 bytes --]
On Wed 13 Sep 15:28 CEST 2006, Fredrik Roubert wrote:
> > Matt's u-boot patches address the issue well for 85xx, they are
> > straightforward to adapt to 83xx:
> >
> > http://sourceforge.net/mailarchive/forum.php?thread_id=15518792&forum_id=12898
>
> OK, I've adapted and applied those patches now.
In case someone else also is interested in using Matt's flat device tree
patches with U-Boot 1.1.4, I've posted my backport of the relevant parts
of the patch to the u-boot-users mailing list now.
Cheers // Fredrik Roubert
--
Visserij 192 | +32 473 344527 / +46 708 776974
BE-9000 Gent | http://www.df.lth.se/~roubert/
[-- Attachment #2: Type: application/pgp-signature, Size: 303 bytes --]
^ 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