LinuxPPC-Dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [4/5][POWERPC] boot: Makefile and linker scripts for zImage.kexec
From: Milton Miller @ 2006-07-01 23:46 UTC (permalink / raw)
  To: linuxppc-dev; +Cc: Paul Mackerras, Sam Ravnborg
In-Reply-To: <kexec-zImage-try2@bga.com>

The Makefile and linker script changes to build zImage.kexec

This patch is based after the if_changed_dep patch.

Signed-off-by: Milton Miller <miltonm@bga.com>

Index: kernel/arch/powerpc/boot/Makefile
===================================================================
--- kernel.orig/arch/powerpc/boot/Makefile	2006-07-01 01:33:55.937370129 -0500
+++ kernel/arch/powerpc/boot/Makefile	2006-07-01 01:41:52.895398201 -0500
@@ -32,12 +32,22 @@ OBJCOPY_MIB_ARGS  := -O aixcoff-rs6000 -
 zlib       := infblock.c infcodes.c inffast.c inflate.c inftrees.c infutil.c
 zlibheader := infblock.h infcodes.h inffast.h inftrees.h infutil.h
 linuxheader := zlib.h zconf.h zutil.h
+linuxheader += stringify.h
 
-src-boot := crt0.S string.S prom.c stdio.c main.c div64.S
-src-boot += $(zlib)
+src-common := string.S stdio.c main.c div64.S
+src-common += $(zlib)
+
+src-boot := crt0.S prom.c  $(src-common)
 src-boot := $(addprefix $(obj)/, $(src-boot))
 obj-boot := $(addsuffix .o, $(basename $(src-boot)))
 
+src-kexec := crt0_kexec.S kexec.c $(src-common)
+src-kexec := $(addprefix $(obj)/, $(src-kexec))
+obj-kexec := $(addsuffix .o, $(basename $(src-kexec)))
+
+src-mult := $(sort $(src-boot) $(src-kexec))
+obj-mult := $(sort $(obj-boot) $(obj-kexec))
+
 BOOTCFLAGS	+= -I$(obj) -I$(srctree)/$(obj)
 
 quiet_cmd_copy_zlib = COPY    $@
@@ -61,7 +71,7 @@ $(addprefix $(obj)/,$(linuxheader)): $(o
 	$(call if_changed,copy_linuxheader)
 
 targets += $(zlib) $(zlibheader) $(linuxheader)
-targets += $(patsubst $(obj)/%,%, $(obj-boot))
+targets += $(patsubst $(obj)/%,%, $(obj-mult))
 
 
 quiet_cmd_bootcc = BOOTCC  $@
@@ -73,10 +83,10 @@ quiet_cmd_bootas = BOOTAS  $@
 quiet_cmd_bootld = BOOTLD  $@
       cmd_bootld = $(CROSS32LD) -T $(srctree)/$(src)/$(3) -o $@ $(2)
 
-$(patsubst %.c,%.o, $(filter %.c, $(src-boot))): %.o: %.c FORCE
+$(patsubst %.c,%.o, $(filter %.c, $(src-mult))): %.o: %.c FORCE
 	$(call if_changed_dep,bootcc)
 
-$(patsubst %.S,%.o, $(filter %.S, $(src-boot))): %.o: %.S FORCE
+$(patsubst %.S,%.o, $(filter %.S, $(src-mult))): %.o: %.S FORCE
 	$(call if_changed_dep,bootas)
 
 $(obj-boot):  COPYHEADERS
@@ -97,6 +107,7 @@ hostprogs-y		:= addnote addRamDisk hack-
 
 targets += zImage.vmode zImage.initrd.vmode zImage zImage.initrd \
 	   zImage.coff zImage.initrd.coff miboot.image miboot.initrd.image \
+	   zImage.kexec zImage.kexec.3264 zImage.kexec64 \
 	   $(patsubst $(obj)/%,%, $(call obj-sec, $(required) $(initrd))) \
 	   $(patsubst $(obj)/%,%, $(call src-sec, $(required) $(initrd))) \
 	   $(patsubst $(obj)/%,%, $(call gz-sec, $(required) $(initrd))) \
@@ -121,7 +132,7 @@ quiet_cmd_addsection = ADDSEC  $@
 		--set-section-flags=.kernel:$(strip $(patsubst $(obj)/kernel-%.o,%, $@))=$(OBJCOPY_SEC_FLAGS)
 
 quiet_cmd_addnote = ADDNOTE $@
-      cmd_addnote = @cp -f $< $@ && \
+      cmd_addnote = cp -f $< $@ && \
 		    $(obj)/addnote $@
 
 quiet_cmd_gen-miboot = GEN     $@
@@ -172,8 +183,35 @@ coffrdimg-$(CONFIG_PPC_PMAC)-$(CONFIG_PP
 mibootimg-$(CONFIG_PPC_PMAC)-$(CONFIG_PPC32) := $(obj)/miboot.image
 mibrdimg-$(CONFIG_PPC_PMAC)-$(CONFIG_PPC32)  := $(obj)/miboot.initrd.image
 
+# The kexec entry point is valid for all kernels.  This zImage should work
+# on all loaders (kexec or firmware) that do not use an openfirmware prom
+# callback, assuming the memory node constraints are met.
+#
+# Build if CONFIG_KEXEC=y or on master make zImage.kexec.
+#
+kexecimg-$(CONFIG_KEXEC)-$(CONFIG_PPC64) += $(obj)/zImage.kexec64
+kexecimg-$(CONFIG_KEXEC)-y               += $(obj)/zImage.kexec
+
+# Build 64 bit and 32 bit package when 64 bit kernel is being built
+$(obj)/zImage.kexec: $(filter-out $(obj)/zImage.kexec, $(kexecimg-y-y))
+
+$(obj)/zImage.kexec: obj-kexec += $(call obj-sec, $(required))
+$(obj)/zImage.kexec: $(obj-kexec) $(srctree)/$(src)/zImage.kexec.lds \
+		$(call obj-sec, $(required)) FORCE
+	$(call if_changed,bootld,$(obj-kexec),zImage.kexec.lds)
+	@true
+
+$(obj)/zImage.kexec.3264: obj-kexec += $(call obj-sec, $(required))
+$(obj)/zImage.kexec.3264: $(obj-kexec) $(srctree)/$(src)/zImage.kexec64.lds \
+		$(call obj-sec, $(required)) FORCE
+	$(call if_changed,bootld,$(obj-kexec),zImage.kexec64.lds)
+
+OBJCOPYFLAGS_zImage.kexec64 := -I elf32-powerpc -O elf64-powerpc
+$(obj)/zImage.kexec64: $(obj)/zImage.kexec.3264 FORCE
+	$(call if_changed,objcopy,$< $@)
+
 $(obj)/zImage: $(obj)/zImage.vmode $(obj)/addnote $(coffimage-y-y) \
-			$(mibootimg-y-y) FORCE
+			$(mibootimg-y-y) $(kexecimg-y-y) FORCE
 	$(call if_changed,addnote)
 	@true
 
@@ -231,4 +269,4 @@ $(obj)/uImage: $(obj)/vmlinux.gz
 install: $(CONFIGURE) $(BOOTIMAGE)
 	sh -x $(srctree)/$(src)/install.sh "$(KERNELRELEASE)" vmlinux System.map "$(INSTALL_PATH)" "$(BOOTIMAGE)"
 
-clean-files += $(addprefix $(objtree)/, $(obj-boot) vmlinux.strip)
+clean-files += $(addprefix $(objtree)/, $(obj-mult) vmlinux.strip)
Index: kernel/arch/powerpc/Makefile
===================================================================
--- kernel.orig/arch/powerpc/Makefile	2006-07-01 01:30:31.108598026 -0500
+++ kernel/arch/powerpc/Makefile	2006-07-01 01:34:26.665172415 -0500
@@ -147,7 +147,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 zImage.kexec znetboot znetboot.initrd vmlinux.sm uImage vmlinux.bin
 
 PHONY += $(BOOT_TARGETS)
 
Index: kernel/arch/powerpc/boot/zImage.kexec.lds
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ kernel/arch/powerpc/boot/zImage.kexec.lds	2006-07-01 01:40:22.459982024 -0500
@@ -0,0 +1,51 @@
+OUTPUT_ARCH(powerpc:common)
+ENTRY(master)
+SECTIONS
+{
+  . = 0;
+  _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);
+  __stack_start =  .;
+  .stack : { *(.stack) }
+  __stack_end =  .;
+
+  . = ALIGN(4096);
+  __bss_start = .;
+  .bss       :
+  {
+   *(.sbss)
+   *(.bss)
+  }
+  . = ALIGN(4096);
+  _end = . ;
+}
Index: kernel/arch/powerpc/boot/zImage.kexec64.lds
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ kernel/arch/powerpc/boot/zImage.kexec64.lds	2006-07-01 01:40:22.487977592 -0500
@@ -0,0 +1,52 @@
+OUTPUT_ARCH(powerpc:common)
+ENTRY(_master64)
+SECTIONS
+{
+  . = 0;
+  _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);
+  __stack_start =  .;
+  .stack : { *(.stack) }
+  __stack_end =  .;
+
+  . = ALIGN(4096);
+  __bss_start = .;
+  .bss       :
+  {
+   *(.sbss)
+   *(.bss)
+  }
+  . = ALIGN(4096);
+  _end = . ;
+}
+

^ permalink raw reply

* [5/5][POWERPC] boot: generate lds file from lds.S
From: Milton Miller @ 2006-07-01 23:47 UTC (permalink / raw)
  To: linuxppc-dev; +Cc: Sam Ravnborg
In-Reply-To: <kexec-zImage-try2@bga.com>

The zImage.kexec and zImage.kexec64 linker files are almost identical to
the base elf file.   Use the lds.S -> ld rule to share the source.

Tell the linker the fils is in $(obj) not $(srctree)/$(src)
zImage.coff.lds is different, it links the initrd and kernel in .data
rather than as a seperate section and without alignment, keep it seperate
for now.

Signed-off-by: Milton Miller <miltonm@bga.com>

Index: kernel/arch/powerpc/boot/Makefile
===================================================================
--- kernel.orig/arch/powerpc/boot/Makefile	2006-07-01 01:41:52.895398201 -0500
+++ kernel/arch/powerpc/boot/Makefile	2006-07-01 01:42:18.569198987 -0500
@@ -81,7 +81,7 @@ 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)
+      cmd_bootld = $(CROSS32LD) -T $(obj)/$(3) -o $@ $(2)
 
 $(patsubst %.c,%.o, $(filter %.c, $(src-mult))): %.o: %.c FORCE
 	$(call if_changed_dep,bootcc)
@@ -108,6 +108,7 @@ hostprogs-y		:= addnote addRamDisk hack-
 targets += zImage.vmode zImage.initrd.vmode zImage zImage.initrd \
 	   zImage.coff zImage.initrd.coff miboot.image miboot.initrd.image \
 	   zImage.kexec zImage.kexec.3264 zImage.kexec64 \
+	   zImage.lds zImage.kexec.lds zImage.kexec64.lds zImage.coff.lds \
 	   $(patsubst $(obj)/%,%, $(call obj-sec, $(required) $(initrd))) \
 	   $(patsubst $(obj)/%,%, $(call src-sec, $(required) $(initrd))) \
 	   $(patsubst $(obj)/%,%, $(call gz-sec, $(required) $(initrd))) \
@@ -168,12 +169,26 @@ $(call obj-sec, $(required) $(initrd)): 
 	$(call cmd,bootcc)
 	$(call cmd,addsection)
 
+lds-fl := -P -C -Upowerpc
+CPPFLAGS_zImage.coff.lds	:= $(lds-fl)
+CPPFLAGS_zImage.lds		:= $(lds-fl) -D__ENTRY__=_zimage_start
+CPPFLAGS_zImage.lds			+= -D__BASE__="4*1024*1024"
+CPPFLAGS_zImage.kexec.lds	:= $(lds-fl) -D__ENTRY__=master -D__BASE__=0
+CPPFLAGS_zImage.kexec64.lds	:= $(lds-fl) -D__ENTRY__=_master64 -D__BASE__=0
+
+$(addprefix $(obj)/, zImage.lds zImage.kexec.lds zImage.kexec64.lds): \
+		$(srctree)/$(src)/zImage.lds.S FORCE
+	$(call if_changed_dep,cpp_lds_S)
+
+$(obj)/zImage.coff.lds:  $(srctree)/$(src)/$zImage.coff.lds.S FORCE
+	$(call if_changed_dep,cpp_lds_S)
+
 $(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 FORCE
+$(obj)/zImage.vmode: $(call obj-sec, $(required)) $(obj-boot) $(obj)/zImage.lds FORCE
 	$(call if_changed,bootld,$(obj-boot),zImage.lds)
 
 $(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 FORCE
+$(obj)/zImage.initrd.vmode: $(call obj-sec, $(required) $(initrd)) $(obj-boot) $(obj)/zImage.lds FORCE
 	$(call if_changed,bootld,$(obj-boot),zImage.lds)
 
 # For 32-bit powermacs, build the COFF and miboot images
@@ -196,13 +211,13 @@ kexecimg-$(CONFIG_KEXEC)-y              
 $(obj)/zImage.kexec: $(filter-out $(obj)/zImage.kexec, $(kexecimg-y-y))
 
 $(obj)/zImage.kexec: obj-kexec += $(call obj-sec, $(required))
-$(obj)/zImage.kexec: $(obj-kexec) $(srctree)/$(src)/zImage.kexec.lds \
+$(obj)/zImage.kexec: $(obj-kexec) $(obj)/zImage.kexec.lds \
 		$(call obj-sec, $(required)) FORCE
 	$(call if_changed,bootld,$(obj-kexec),zImage.kexec.lds)
 	@true
 
 $(obj)/zImage.kexec.3264: obj-kexec += $(call obj-sec, $(required))
-$(obj)/zImage.kexec.3264: $(obj-kexec) $(srctree)/$(src)/zImage.kexec64.lds \
+$(obj)/zImage.kexec.3264: $(obj-kexec) $(obj)/zImage.kexec64.lds \
 		$(call obj-sec, $(required)) FORCE
 	$(call if_changed,bootld,$(obj-kexec),zImage.kexec64.lds)
 
@@ -221,12 +236,11 @@ $(obj)/zImage.initrd: $(obj)/zImage.init
 	@true
 
 $(obj)/zImage.coff: $(call obj-sec, $(required)) $(obj-boot) \
-			$(srctree)/$(src)/zImage.coff.lds $(obj)/hack-coff FORCE
+			$(obj)/zImage.coff.lds $(obj)/hack-coff FORCE
 	$(call if_changed_rule,ldcoff,$(obj-boot),zImage.coff.lds)
 
 $(obj)/zImage.initrd.coff: $(call obj-sec, $(required) $(initrd)) $(obj-boot) \
-			   $(srctree)/$(src)/zImage.coff.lds $(obj)/hack-coff \
-			   FORCE
+			   $(obj)/zImage.coff.lds $(obj)/hack-coff FORCE
 	$(call if_changed_rule,ldcoff,$(obj-boot),zImage.coff.lds)
 
 $(obj)/miboot.image: $(obj)/dummy.o $(obj)/vmlinux.gz FORCE
Index: kernel/arch/powerpc/boot/zImage.coff.lds
===================================================================
--- kernel.orig/arch/powerpc/boot/zImage.coff.lds	2006-07-01 01:40:22.406990413 -0500
+++ /dev/null	1970-01-01 00:00:00.000000000 +0000
@@ -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)
-  }
-}
Index: kernel/arch/powerpc/boot/zImage.coff.lds.S
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ kernel/arch/powerpc/boot/zImage.coff.lds.S	2006-07-01 01:42:18.572198512 -0500
@@ -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)
+  }
+}
Index: kernel/arch/powerpc/boot/zImage.kexec.lds
===================================================================
--- kernel.orig/arch/powerpc/boot/zImage.kexec.lds	2006-07-01 01:40:22.459982024 -0500
+++ /dev/null	1970-01-01 00:00:00.000000000 +0000
@@ -1,51 +0,0 @@
-OUTPUT_ARCH(powerpc:common)
-ENTRY(master)
-SECTIONS
-{
-  . = 0;
-  _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);
-  __stack_start =  .;
-  .stack : { *(.stack) }
-  __stack_end =  .;
-
-  . = ALIGN(4096);
-  __bss_start = .;
-  .bss       :
-  {
-   *(.sbss)
-   *(.bss)
-  }
-  . = ALIGN(4096);
-  _end = . ;
-}
Index: kernel/arch/powerpc/boot/zImage.kexec64.lds
===================================================================
--- kernel.orig/arch/powerpc/boot/zImage.kexec64.lds	2006-07-01 01:40:22.487977592 -0500
+++ /dev/null	1970-01-01 00:00:00.000000000 +0000
@@ -1,52 +0,0 @@
-OUTPUT_ARCH(powerpc:common)
-ENTRY(_master64)
-SECTIONS
-{
-  . = 0;
-  _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);
-  __stack_start =  .;
-  .stack : { *(.stack) }
-  __stack_end =  .;
-
-  . = ALIGN(4096);
-  __bss_start = .;
-  .bss       :
-  {
-   *(.sbss)
-   *(.bss)
-  }
-  . = ALIGN(4096);
-  _end = . ;
-}
-
Index: kernel/arch/powerpc/boot/zImage.lds
===================================================================
--- kernel.orig/arch/powerpc/boot/zImage.lds	2006-07-01 01:40:22.516973001 -0500
+++ /dev/null	1970-01-01 00:00:00.000000000 +0000
@@ -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 = . ;
-}
Index: kernel/arch/powerpc/boot/zImage.lds.S
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ kernel/arch/powerpc/boot/zImage.lds.S	2006-07-01 01:42:18.576197879 -0500
@@ -0,0 +1,51 @@
+OUTPUT_ARCH(powerpc:common)
+ENTRY(__ENTRY__)
+SECTIONS
+{
+  . = __BASE__;
+  _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);
+  __stack_start =  .;
+  .stack : { *(.stack) }
+  __stack_end =  .;
+
+  . = ALIGN(4096);
+  __bss_start = .;
+  .bss       :
+  {
+   *(.sbss)
+   *(.bss)
+  }
+  . = ALIGN(4096);
+  _end = . ;
+}

^ permalink raw reply

* Re: OSS driver removal, 2nd round
From: Adrian Bunk @ 2006-07-01 23:12 UTC (permalink / raw)
  To: linux-kernel; +Cc: linuxppc-dev, alsa-devel, Johannes Berg, perex, Olaf Hering
In-Reply-To: <20060629192128.GE19712@stusta.de>

On Thu, Jun 29, 2006 at 09:21:28PM +0200, Adrian Bunk wrote:

> Now that I've sent the first round of actually removing the code for OSS 
> drivers where ALSA drivers without regressions exist for the same 
> hardware, it's time for a second round amongst the remaining drivers.
> 
> 
> Removing OSS drivers where ALSA drivers for the same hardware exists has 
> two reasons:
> 
> 1. remove obsolete and mostly unmaintained code
> 2. get bugs in the ALSA drivers reported that weren't previously
>    reported due to the possible workaround of using the OSS drivers
> 
> 
> The list below divides the OSS drivers into the following three
> categories:
> 1. ALSA drivers for the same hardware
> 2. ALSA drivers for the same hardware with known problems
> 3. no ALSA drivers for the same hardware
> 
> 
> My proposed timeline is:
> - 2.6.18: let the drivers under 1. in the list below depend on
>           OSS_OBSOLETE_DRIVER
> - 2.6.20: remove the options depending on OSS_OBSOLETE_DRIVER
> - 2.6.22: remove the code for the drivers that were depending on
>           OSS_OBSOLETE_DRIVER from the kernel tree
>...
> 2. ALSA drivers for the same hardware with known problems
> 
> DMASOUND_PMAC
> - Olaf Hering regarding regressions in SND_POWERMAC:
>   Some tumbler models work only after one plug/unplug cycle of
>   the headphone. early powerbooks report/handle the mute settings
>   incorrectly. there are likely more bugs.
>...

Could anyone tell me whether there are still regressions in ALSA 
compared to DMASOUND_PMAC, and if yes give me bug numbers in the 
ALSA BTS so that I can track them?

TIA
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

^ permalink raw reply

* [PATCH] powermac: Fix some 64b resource damage
From: Benjamin Herrenschmidt @ 2006-07-02  1:55 UTC (permalink / raw)
  To: Andrew Morton, Linus Torvalds
  Cc: linuxppc-dev list, Greg Kroah-Hartman, Paul Mackerras

The 64 bits resource patches did a bit of damage on PowerMac causing a
buffer overflow in macio_asic and a warning in a sound driver. The
former is fixed by reverting the sprintf of the bus_id to %08x as it was
before. The bus_id used for macio devices is always a 32 bits value
(macio always sits in 32 bits space) and since it's exposed to userland,
the format of the string shouldn't be changed like that anyway. The
second by using the proper type for printk.

Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
Linus, please apply asap since right now, PowerMac overflows kobject
buffers on boot, pretty bad.


Index: linux-irq-work/drivers/macintosh/macio_asic.c
===================================================================
--- linux-irq-work.orig/drivers/macintosh/macio_asic.c	2006-07-02 11:46:53.000000000 +1000
+++ linux-irq-work/drivers/macintosh/macio_asic.c	2006-07-02 11:47:37.000000000 +1000
@@ -427,10 +427,10 @@
 
 	/* MacIO itself has a different reg, we use it's PCI base */
 	if (np == chip->of_node) {
-		sprintf(dev->ofdev.dev.bus_id, "%1d.%016llx:%.*s",
+		sprintf(dev->ofdev.dev.bus_id, "%1d.%08x:%.*s",
 			chip->lbus.index,
 #ifdef CONFIG_PCI
-			(unsigned long long)pci_resource_start(chip->lbus.pdev, 0),
+			(unsigned int)pci_resource_start(chip->lbus.pdev, 0),
 #else
 			0, /* NuBus may want to do something better here */
 #endif
Index: linux-irq-work/sound/ppc/pmac.c
===================================================================
--- linux-irq-work.orig/sound/ppc/pmac.c	2006-07-02 11:46:53.000000000 +1000
+++ linux-irq-work/sound/ppc/pmac.c	2006-07-02 11:48:40.000000000 +1000
@@ -1170,7 +1170,7 @@
 					       chip->rsrc[i].start + 1,
 					       rnames[i]) == NULL) {
 				printk(KERN_ERR "snd: can't request rsrc "
-				       " %d (%s: 0x%016lx:%016lx)\n",
+				       " %d (%s: 0x%016llx:%016llx)\n",
 				       i, rnames[i],
 				       (unsigned long long)chip->rsrc[i].start,
 				       (unsigned long long)chip->rsrc[i].end);

^ permalink raw reply

* RE: [PATCH] powerpc:Fix rheap alignment problem
From: Rune Torgersen @ 2006-07-02  3:54 UTC (permalink / raw)
  To: Pantelis Antoniou, Kumar Gala
  Cc: linuxppc-dev list, Paul Mackerras, linux-kernel
In-Reply-To: <200607011750.05019.pantelis.antoniou@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 808 bytes --]

From: Pantelis Antoniou
Sent: Sat 7/1/2006 9:50 AM
>Since genalloc is the blessed linux thing it might be best to use that & remove
>rheap completely. Oh well...

Two problems with genalloc that I can see (for CPM programming):
1) (minor) Does not have a way to specify alignment (genalloc does it for you)
2) (major problerm, at least for me) Does not have a way to allocate a specified address in the pool.

2 is needed esp when programming MCC drivers, since a lot of the datastructures must be in DP RAM _and_ be in a specific spot. And if you cannot tell the allocator that I am using a specific address, then the allocator might very well give somebody else that portion of RAM. The only solution without a fixed allocator is to allocate ALL memory in the DP RAM and use your own allocator. 

[-- Attachment #2: Type: text/html, Size: 1247 bytes --]

^ permalink raw reply

* [PATCH] powerpc: Fix warning in cell setup.c
From: Benjamin Herrenschmidt @ 2006-07-02  4:30 UTC (permalink / raw)
  To: Paul Mackerras; +Cc: Andrew Morton, linuxppc-dev list, Arnd Bergmann

Fixes a warning due to a missing #include on cell

Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

Index: linux-irq-work/arch/powerpc/platforms/cell/setup.c
===================================================================
--- linux-irq-work.orig/arch/powerpc/platforms/cell/setup.c	2006-07-01 15:25:33.000000000 +1000
+++ linux-irq-work/arch/powerpc/platforms/cell/setup.c	2006-07-01 15:25:36.000000000 +1000
@@ -49,6 +49,7 @@
 #include <asm/irq.h>
 #include <asm/spu.h>
 #include <asm/spu_priv1.h>
+#include <asm/udbg.h>
 
 #include "interrupt.h"
 #include "iommu.h"

^ permalink raw reply

* Re: [PATCH] powermac: Fix some 64b resource damage
From: Greg KH @ 2006-07-02  4:05 UTC (permalink / raw)
  To: Benjamin Herrenschmidt
  Cc: Andrew Morton, linuxppc-dev list, Linus Torvalds, Paul Mackerras
In-Reply-To: <1151805303.19419.15.camel@localhost.localdomain>

On Sun, Jul 02, 2006 at 11:55:03AM +1000, Benjamin Herrenschmidt wrote:
> The 64 bits resource patches did a bit of damage on PowerMac causing a
> buffer overflow in macio_asic and a warning in a sound driver. The
> former is fixed by reverting the sprintf of the bus_id to %08x as it was
> before. The bus_id used for macio devices is always a 32 bits value
> (macio always sits in 32 bits space) and since it's exposed to userland,
> the format of the string shouldn't be changed like that anyway. The
> second by using the proper type for printk.
> 
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
> Linus, please apply asap since right now, PowerMac overflows kobject
> buffers on boot, pretty bad.

Acked by me, sorry about this.

greg k-h

^ permalink raw reply

* Re: [PATCH] powerpc:Fix rheap alignment problem
From: Pantelis Antoniou @ 2006-07-02  5:18 UTC (permalink / raw)
  To: Rune Torgersen; +Cc: linuxppc-dev list, Paul Mackerras, linux-kernel
In-Reply-To: <DCEAAC0833DD314AB0B58112AD99B93B07B36F@ismail.innsys.innovsys.com>

On Sunday 02 July 2006 06:54, Rune Torgersen wrote:
> From: Pantelis Antoniou
> Sent: Sat 7/1/2006 9:50 AM
> >Since genalloc is the blessed linux thing it might be best to use that & remove
> >rheap completely. Oh well...
> 
> Two problems with genalloc that I can see (for CPM programming):
> 1) (minor) Does not have a way to specify alignment (genalloc does it for you)
> 2) (major problerm, at least for me) Does not have a way to allocate a specified address in the pool.
> 
> 2 is needed esp when programming MCC drivers, since a lot of the datastructures must be in DP RAM _and_ be in a specific spot. And if you cannot tell the allocator that I am using a specific address, then the allocator might very well give somebody else that portion of RAM. The only solution without a fixed allocator is to allocate ALL memory in the DP RAM and use your own allocator. 
> 

Yeah, that too.

Too bad there are no main tree drivers like that, but they do exist.

One could conceivably hack genalloc to do that, but will end up with
something complex too.

BTW, there are other uEngine based architectures with similar alignment
requirements.

So in conclusion, for the in-tree drivers genalloc is sufficient as an cpm memory allocator.
For some out of tree drivers, it is not.

Pantelis

^ permalink raw reply

* Re: [PATCH] powerpc: Fix warning in cell setup.c
From: Andrew Morton @ 2006-07-02  6:08 UTC (permalink / raw)
  To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, paulus, arnd
In-Reply-To: <1151814604.19419.20.camel@localhost.localdomain>

On Sun, 02 Jul 2006 14:30:04 +1000
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:

> Fixes a warning due to a missing #include on cell
> 
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> 
> Index: linux-irq-work/arch/powerpc/platforms/cell/setup.c
> ===================================================================
> --- linux-irq-work.orig/arch/powerpc/platforms/cell/setup.c	2006-07-01 15:25:33.000000000 +1000
> +++ linux-irq-work/arch/powerpc/platforms/cell/setup.c	2006-07-01 15:25:36.000000000 +1000
> @@ -49,6 +49,7 @@
>  #include <asm/irq.h>
>  #include <asm/spu.h>
>  #include <asm/spu_priv1.h>
> +#include <asm/udbg.h>
>  
>  #include "interrupt.h"
>  #include "iommu.h"

I already had that.

I don't know what to do with powerpc patches any more.  Help.

^ permalink raw reply

* Re: [PATCH] powerpc: Fix warning in cell setup.c
From: Benjamin Herrenschmidt @ 2006-07-02  6:40 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linuxppc-dev, paulus, arnd
In-Reply-To: <20060701230845.e2f8507d.akpm@osdl.org>

On Sat, 2006-07-01 at 23:08 -0700, Andrew Morton wrote:
> On Sun, 02 Jul 2006 14:30:04 +1000
> Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> 
> > Fixes a warning due to a missing #include on cell
> > 
> > Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> > 
> > Index: linux-irq-work/arch/powerpc/platforms/cell/setup.c
> > ===================================================================
> > --- linux-irq-work.orig/arch/powerpc/platforms/cell/setup.c	2006-07-01 15:25:33.000000000 +1000
> > +++ linux-irq-work/arch/powerpc/platforms/cell/setup.c	2006-07-01 15:25:36.000000000 +1000
> > @@ -49,6 +49,7 @@
> >  #include <asm/irq.h>
> >  #include <asm/spu.h>
> >  #include <asm/spu_priv1.h>
> > +#include <asm/udbg.h>
> >  
> >  #include "interrupt.h"
> >  #include "iommu.h"
> 
> I already had that.
> 
> I don't know what to do with powerpc patches any more.  Help.

If you already have it, drop it :) I didnt notice it was already there.
For trivialities like that, it doesn't matter. Important stuff goes
through paulus.

Ben.

^ permalink raw reply

* Re: sound connector detection
From: Richard Purdie @ 2006-07-02  9:28 UTC (permalink / raw)
  To: Dmitry Torokhov
  Cc: Liam Girdwood, Linux Kernel list, linuxppc-dev list, linux-input,
	Johannes Berg, alsa-devel
In-Reply-To: <200607011609.59426.dtor@insightbb.com>

Hi,

On Sat, 2006-07-01 at 16:09 -0400, Dmitry Torokhov wrote:
> I am not too happy with putting this kind of switches into input layer,
> it should be reserved for "real" buttons, ones that user can explicitely
> push or toggle 

Playing devil's advocate, by inserting a headphone cable, you push the
switch - the user can explicitly control that switch but inserting or
removing the cable...

> (lid switch is on the edge here but it and sleep button
> are used for similar purposes so it makes sense to have it in input layer
> too). But "cable X connected" kind of events is too much [for input layer,
> there could well be a separate layer for it]. If we go this way we'd have
> to move cable detection code from network to input layer as well ;)

I have mixed feelings about this and can see it from both sides. In a
lot of cases, we need to report these "switch" events to userspace as
only userspace can determine the correct action. Taking some examples,
just from the Zaurus:

Upon lid closure should:
  - the screen/backlight be turned off?
  - the device suspended?

Upon insertion of a headphone jack should:
  - the external speaker be turned on/off?
  - does the jack connect to headphones, a headset, mic or line in
source? (no autodetection so the user has to select and only then can
the mixer be appropriately configured)

Only userspace can make these decisions so we need to pass them there so
it can decide how to handle things. In the case of the Zaurus, we have a
program called zaurusd which listens for the events and knows how to
handle them (http://svn.o-hand.com/view/misc/trunk/zaurusd/). It turns
these events into something the user can influence with scripts.

There is also a question of which USB client to load when  USB client is
detected - again, this insertion event really needs to be passed to
userspace for a decision. I've not touched this issue yet and adding
switch events for client cable detection would probably get frowned
upon?

One thing the input system does well is pass simple switch events to
userspace though its event devices. Not using the input system for
switch like events like these is going to result in code duplication.

I can understand the concern with not wanting to fill the input
subsystem with events that have a tenuous relationship to input devices.
Perhaps the solution is to separate the events layer from the input
layer and start to allow it to handle more generic events?

One of the issues is the ownership of the events data. Currently, you
can't tag a given source of events to a given soundcard. Perhaps each
soundcard would create a separate events device but we need to think
about things like this. Some switch events have no real parent (like the
lid switch on the Zaurus which if anything does belong to the keyboard
driver). Others like the headphone switch on the zaurus arguably belong
to the ASoC sound device (not in mainline yet but coming soon).

In the audio case, there is perhaps an argument for some kind of
scenarios handling where the mixer has some predefined states which get
activated given certain circumstances. The Zaurus ASoC implementations
already sort of implement this having controls which set the headphone
jack mode (headphones, headset, mic, line, off). There is still a need
to ask userspace what was inserted though which requires some kind of
event system.

Even if the audio situation improves, it doesn't solve the general event
case either. Can anyone see a way forward? Would some kind of generic
event code that any device could add to its sysfs directory work? Could
such a thing be abstracted from the input system code?

Richard

^ permalink raw reply

* RE: rs232 endianness on PPC
From: Antonio Di Bacco @ 2006-07-02 10:10 UTC (permalink / raw)
  To: linuxppc-embedded

PowerPC is neither byte swapped nor bit swapped.
When transmitting on a network card the most significant byte is transmitted 
first, and, inside the byte, the most significant bit is sent first.
RS232 is an exception: LSB is sent first.

^ permalink raw reply

* [PATCH 2.6.17] Add -fno-stack-protector to BOOTCFLAGS in arch/powerpc/boot/Makefile.
From: Niels Kristian Bech Jensen @ 2006-07-02 11:02 UTC (permalink / raw)
  To: linuxppc-dev

[-- Attachment #1: Type: text/plain, Size: 389 bytes --]

I got some undefined references to __stack_chk_fail in
arch/powerpc/boot/stdio.o and arch/powerpc/boot/prom.o when I was trying
to build a kernel on Ubuntu Edgy Eft - which includes Stack Smashing
Protection.

This patch adds -fno-stack-protector to BOOTCFLAGS in
arch/powerpc/boot/Makefile (why does BOOTCFLAGS depend on HOSTCFLAGS and
not CFLAGS?).

Regards,
Niels Kristian Bech Jensen


[-- Attachment #2: powerpc-2.6.17.diff --]
[-- Type: text/x-patch, Size: 492 bytes --]

--- linux-source-2.6.17/arch/powerpc/boot/Makefile~	2006-06-29 03:23:03.000000000 +0200
+++ linux-source-2.6.17/arch/powerpc/boot/Makefile	2006-07-02 12:44:34.000000000 +0200
@@ -41,6 +41,10 @@ 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)
 
 quiet_cmd_copy_zlib = COPY    $@

^ permalink raw reply

* Problem booting Linux on MPC8XXFADS
From: Hamid Marshall @ 2006-07-02 21:41 UTC (permalink / raw)
  To: linuxppc-embedded; +Cc: boehringer

[-- Attachment #1: Type: text/plain, Size: 167 bytes --]

Hi Sven,

Were you able to resolve your Linux boot problem on this board. Let me know
what steps you took to resolve this.

 

 

Thanks,

 

 

 

Hamid Marshall

 


[-- Attachment #2: Type: text/html, Size: 2915 bytes --]

^ permalink raw reply

* Re: sound connector detection
From: Dmitry Torokhov @ 2006-07-03  2:48 UTC (permalink / raw)
  To: Richard Purdie
  Cc: Liam Girdwood, Linux Kernel list, linuxppc-dev list, linux-input,
	Johannes Berg, alsa-devel
In-Reply-To: <1151832510.5536.32.camel@localhost.localdomain>

[-- Attachment #1: Type: text/plain, Size: 897 bytes --]

On Sunday 02 July 2006 05:28, Richard Purdie wrote:
> One thing the input system does well is pass simple switch events to
> userspace though its event devices. Not using the input system for
> switch like events like these is going to result in code duplication.
> 

I think that hotplug/uevent like mechanism would be better suited here.
You want to monitor changes in system state and you do not really want
to monitor myriad of devices but just latch onto one data feed and get
all the data from it (unlike input devices where you might want to
separate data coming from different devices). The following "event"
might be a good starting point:

	struct system_change_event {
		struct timeval time;	/* look for 32/64 bit issues */
		__u16 type;
		__u16 code;
		__s32 value;
		char object_path[224];
};

Maybe we should start looking into connector or a pure netlink implementation.

-- 
Dmitry

[-- Attachment #2: Type: text/html, Size: 1217 bytes --]

^ permalink raw reply

* RE: [PATCH] Add QE device tree definition
From: Li Yang-r58472 @ 2006-07-03  6:17 UTC (permalink / raw)
  To: Fleming Andy-afleming; +Cc: linuxppc-dev

> -----Original Message-----
> From: Fleming Andy-afleming
> Sent: Saturday, July 01, 2006 1:55 AM
> To: Li Yang-r58472
> Cc: 'Kumar Gala'; linuxppc-dev@ozlabs.org
> Subject: Re: [PATCH] Add QE device tree definition
> 
> 
> On Jun 29, 2006, at 22:36, Li Yang-r58472 wrote:
> 
> >>> +
> >>> +
> >>> +   2) SPI (Serial Peripheral Interface)
> >>> +
> >>> +   Required properties:
> >>> +   - device_type : should be "spi".
> >>> +   - compatible : should be "fsl_spi".
> >>> +   - mode : the spi operation mode, it can be "cpu" or "qe".
> >>
> >> What does it mean for the spi to be in "qe" mode?
> > That means:
> > The SPI can operate in QE mode or in CPU mode. In QE mode SPI is
> > compatible to the MPC826x SPI, and is controlled by QE RISC. In CPU
> > mode, the SPI is controlled wholly by the CPU without any QE RISC
> > intervention.
> 
> 
> Doesn't that mean the "cpu" SPI isn't part of the QE device?  I kind
> of feel like it shouldn't be part of the QE node, then.  Or is it
> actually one device that can act in two different modes?

Yes, it is actually one device with two modes, sharing the same set of registers within QE memory map region.  So it best lives in QE node.
> 
> 
> >
> >>
> >>> +   - reg : offset to the register set and its length.
> >>> +   - interrupts : <a b> where a is the interrupt number and b is a
> >>> +     field that represents an encoding of the sense and level
> >>> +     information for the interrupt.  This should be encoded
> >>> based on
> >>> +     the information in section 2) depending on the type of
> >>> interrupt
> >>> +     controller you have.
> >>> +   - interrupt-parent : the phandle for the interrupt controller
> >>> that
> >>> +     services interrupts for this device.
> >>> +
> >>> +   Example:
> >>> +	spi@4c0 {
> >>> +		device_type = "spi";
> >>> +		compatible = "fsl_spi";
> >>> +		reg = <4c0 40>;
> >>> +		interrupts = <82 0>;
> >>> +		interrupt-parent = <700>;
> >>> +		mode = "cpu";
> >>> +	};
> >>> +
> >>
> >> How do we tell the difference between the various spi controllers.  I
> >> think we have four of them, three of which are probably pretty
> >> similar.  We have the 834x spi, and QE, CPM1, CPM2 SPI.
> >>
> >>> +
> >>> +   3) USB (Universal Serial Bus Controller)
> >>> +
> >>> +   Required properties:
> >>> +   - device_type : should be "usb".
> >>> +   - compatible : could be "qe_udc" or "fhci-hcd".
> >>> +   - model : the could be "host" or "slave".
> >>
> >> got a 'l' on mode, if we are slave should we provide more info about
> >> what kinda slave we are (ie, what gadget driver should apply).
> >>
> >>> +   - reg : there will be two tuples of "address size".  The first
> >>> tuple is
> >>> +     offset and length of the device registers respectively; the
> >>> second is
> >>> +     offset and length of the device parameter RAM respectively.
> >>> +   - interrupts : <a b> where a is the interrupt number and b is a
> >>> +     field that represents an encoding of the sense and level
> >>> +     information for the interrupt.  This should be encoded
> >>> based on
> >>> +     the information in section 2) depending on the type of
> >>> interrupt
> >>> +     controller you have.
> >>> +   - interrupt-parent : the phandle for the interrupt controller
> >>> that
> >>> +     services interrupts for this device.
> >>> +
> >>> +   Example(slave):
> >>> +	usb@6c0 {
> >>> +		device_type = "usb";
> >>> +		compatible = "qe_udc";
> >>> +		reg = <6c0 40 8B00 100>;
> >>> +		interrupts = <8b 0>;
> >>> +		interrupt-parent = <700>;
> >>> +		mode = "slave";
> >>> +	};
> >>> +
> >>> +
> >>> +   4) UCC (Unified Communications Controllers)
> >>
> >> Why dont you create a sub section for network, and in the future
> >> additional subsections can be added for the different device_types.
> >>
> >>> +
> >>> +   Required properties:
> >>> +   - device_type : should be "network", "hldc", "uart",
> >>> "transparent"
> >>> +    "bisync" or "atm".
> >>> +   - compatible : could be "ucc_geth" or "fsl_atm" and so on.
> >>> +   - model : should be "UCC".
> >>> +   - device-id : the ucc number(1-8), corresponding to UCCx in UM.
> >>> +   - reg : there will be two tuples of "address size".  The first
> >>> tuple is
> >>> +     offset and length of the device registers respectively; the
> >>> second is
> >>> +     offset and length of the device parameter RAM respectively.
> >>> +   - interrupts : <a b> where a is the interrupt number and b is a
> >>> +     field that represents an encoding of the sense and level
> >>> +     information for the interrupt.  This should be encoded
> >>> based on
> >>> +     the information in section 2) depending on the type of
> >>> interrupt
> >>> +     controller you have.
> >>> +   - interrupt-parent : the phandle for the interrupt controller
> >>> that
> >>> +     services interrupts for this device.
> >>> +   - pio-handle : The phandle for the Parallel I/O port
> >>> configuration.
> >>> +
> >>> +   Required properties for network device_type:
> >>> +   - mac-address : list of bytes representing the ethernet address.
> >>> +   - rx-clock : a string represents the UCC receive clock source.
> >>> +     "brgx" : clock source is BRG1~BRG16 respectively;
> >>> +     "clkx" : clock source is QE_CLK1~QE_CLK24 respectively.
> >>> +     others : clock source is disabled;
> >>> +   - tx-clock: a string represents the UCC transmit clock source;
> >>> +     "brgx" : clock source is BRG1~BRG16 respectively;
> >>> +     "clkx" : clock source is QE_CLK1~QE_CLK24 respectively.
> >>> +     others : clock source is disabled;
> >>> +   - phy-handle : The phandle for the PHY connected to this
> >>> controller.
> >>> +
> >>> +   Example:
> >>> +	ucc@2000 {
> >>> +		device_type = "network";
> >>> +		compatible = "ucc_geth";
> >>> +		model = "UCC";
> >>> +		device-id = <1>;
> >>> +		reg = <2000 200 8400 100>;
> >>> +		interrupts = <a0 0>;
> >>> +		interrupt-parent = <700>;
> >>> +		mac-address = [ 00 04 9f 00 23 23 ];
> >>> +		rx-clock = "none";
> >>> +		tx-clock = "clk9";
> >>> +		phy-handle = <212000>;
> >>> +		pio-handle = <140001>;
> >>> +	};
> >>> +
> >>> +
> >>> +   5) Parallel I/O Ports
> >>> +
> >>> +   This node configures Parallel I/O ports for CPUs with QE
> >>> support.
> >>> +   The node should reside in the "soc" node of the tree.  For each
> >>> +   device that using parallel I/O ports, a child node should be
> >>> created.
> >>> +   See the definition of the Pin configuration nodes below for more
> >>> +   information.
> >>> +
> >>> +   Required properties:
> >>> +   - device_type : should be "par_io".
> >>> +   - reg : offset to the register set and its length.
> >>> +
> >>> +   Example:
> >>> +	par_io@1400 {
> >>> +		reg = <1400 100>;
> >>> +		#address-cells = <1>;
> >>> +		#size-cells = <0>;
> >>> +		device_type = "par_io";
> >>> +		ucc_pin@01 {
> >>> +			......
> >>> +		};
> >>> +
> >>
> >> Can you explain this further, I'm not getting the relationship
> >> between a par_io & ucc_pin.  An example maybe helpful.
> >
> > Each QE device needs to configure Parallel I/O Ports pin
> > configuration in order to work, for example the configuration for
> > ucc1 is ucc_pin@01.  par_io is a container for all these
> > configurations and gives the base for parallel io port register.  I
> > will paste dts file for 8360 to give an example.
> >>
> >>> +
> >>> +   6) Pin configuration nodes
> >>> +
> >>> +   Required properties:
> >>> +   - linux,phandle : phandle of this node; likely referenced by
> >>> a QE
> >>> +     device.
> >>> +   - pio-map : array of pin configurations.  Each pin is defined
> >>> by 6
> >>> +     integers.  The six numbers are respectively: port, pin, dir,
> >>> +     open_drain, assignment, has_irq.
> >>> +     - port : port number of the pin; 0-6 represent port A-G in UM.
> >>> +     - pin : pin number in the port.
> >>> +     - dir : direction of the pin, should encode as follows:
> >>> +
> >>> +	0 = The pin is disabled
> >>> +	1 = The pin is an output
> >>> +	2 = The pin is an input
> >>> +	3 = The pin is I/O
> >>> +
> >>> +     - open_drain : indicates the pin is normal or wired-OR:
> >>> +
> >>> +	0 = The pin is actively driven as an output
> >>> +	1 = The pin is an open-drain driver. As an output, the pin is
> >>> +	    driven active-low, otherwise it is three-stated.
> >>> +
> >>> +     - assignment : function number of the pin according to the
> >>> Pin Assignment
> >>> +       tables in User Manual.  Each pin can have up to 4 possible
> >>> functions in
> >>> +       QE and two options for CPM.
> >>> +     - has_irq : indicates if the pin is used as source of exteral
> >>> +       interrupts.
> >>> +
> >>> +   Example:
> >>> +	ucc_pin@01 {
> >>> +		linux,phandle = <140001>;
> >>> +		pio-map = <
> >>> +		/* port  pin  dir  open_drain  assignment  has_irq */
> >>> +			0  3  1  0  1  0 	/* TxD0 */
> >>> +			0  4  1  0  1  0 	/* TxD1 */
> >>> +			0  5  1  0  1  0 	/* TxD2 */
> >>> +			0  6  1  0  1  0 	/* TxD3 */
> >>> +			1  6  1  0  3  0 	/* TxD4 */
> >>> +			1  7  1  0  1  0 	/* TxD5 */
> >>> +			1  9  1  0  2  0 	/* TxD6 */
> >>> +			1  a  1  0  2  0 	/* TxD7 */
> >>> +			0  9  2  0  1  0 	/* RxD0 */
> >>> +			0  a  2  0  1  0 	/* RxD1 */
> >>> +			0  b  2  0  1  0 	/* RxD2 */
> >>> +			0  c  2  0  1  0 	/* RxD3 */
> >>> +			0  d  2  0  1  0 	/* RxD4 */
> >>> +			1  1  2  0  2  0 	/* RxD5 */
> >>> +			1  0  2  0  2  0 	/* RxD6 */
> >>> +			1  4  2  0  2  0 	/* RxD7 */
> >>> +			0  7  1  0  1  0 	/* TX_EN */
> >>> +			0  8  1  0  1  0 	/* TX_ER */
> >>> +			0  f  2  0  1  0 	/* RX_DV */
> >>> +			0  10 2  0  1  0 	/* RX_ER */
> >>> +			0  0  2  0  1  0 	/* RX_CLK */
> >>> +			2  9  1  0  3  0 	/* GTX_CLK - CLK10 */
> >>> +			2  8  2  0  1  0>;	/* GTX125 - CLK9 */
> >>> +	};
> >>> +
> >>> +
> >>>     More devices will be defined as this spec matures.
> >>>
> >>>
> >>> _______________________________________________
> >>> Linuxppc-dev mailing list
> >>> Linuxppc-dev@ozlabs.org
> >>> https://ozlabs.org/mailman/listinfo/linuxppc-dev
> > _______________________________________________
> > Linuxppc-dev mailing list
> > Linuxppc-dev@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-dev

^ permalink raw reply

* Re: MPC8548 PCIe / PCI support with BSP MPC8548CDS 02/24/2006
From: Florian Boelstler @ 2006-07-03  6:38 UTC (permalink / raw)
  To: linuxppc-embedded
In-Reply-To: <9FCDBA58F226D911B202000BDBAD467306DD12EC@zch01exm40.ap.freescale.net>

Hi,

Zhang Wei-r63237 schrieb:
> Yes, I think so. You can plug a PCIe ethernet card to test it. 

A single device always works.

> :-), Maybe it's need more study. Could you enable the DEBUG and post the kernel verbose message?

We added lots of debug output and made some modifications (mostly delays 
between calls to early_read_config_dword() and 
early_write_config_dword() in pci_auto.c) and came to the conclusion 
that generic bridge devices (PCIe-to-PCI), even in a cascaded setup of 
three bridges, work fine.

However a PCIe switch (PLX8516/8532) doesn't work. The MPC8548 only 
detects a single device (i.e. primary side of the switch).
We are going to analyze the problem more deeply soon. It seems that the 
configuration space of that devices isn't properly set up.

The provided patch doesn't make any difference, besides that it is moved 
to a location where the PPC itself is not detected.

Please keep us informed if there is any progress besides Freescale, as I 
will do.

Cheers,

   Florian

^ permalink raw reply

* How do you set up a PPC440GX with a PHY on emac2 only?
From: Howard, Marc @ 2006-07-03  5:41 UTC (permalink / raw)
  To: linuxppc-embedded

[-- Attachment #1: Type: text/plain, Size: 396 bytes --]

Hi,

Does anyone have any pointers/tips on how to set up a ocotea-like PPC440GX design with only a single gigabit (Cicada) PHY on emac2?  Editing ocotea_set_emacdata() to just define a single PHY doesn't work correctly.  It looks like this has something to do with the MII communtications being on the ZMII bridge on emac0 but defining emac0 doesn't help either. 

Thanks,

Marc W. Howard

[-- Attachment #2: Type: text/html, Size: 829 bytes --]

^ permalink raw reply

* How do you set up a PPC440GX with a PHY on emac2 only?
From: Howard, Marc @ 2006-07-03  5:41 UTC (permalink / raw)
  To: linuxppc-embedded

[-- Attachment #1: Type: text/plain, Size: 396 bytes --]

Hi,

Does anyone have any pointers/tips on how to set up a ocotea-like PPC440GX design with only a single gigabit (Cicada) PHY on emac2?  Editing ocotea_set_emacdata() to just define a single PHY doesn't work correctly.  It looks like this has something to do with the MII communtications being on the ZMII bridge on emac0 but defining emac0 doesn't help either. 

Thanks,

Marc W. Howard

[-- Attachment #2: Type: text/html, Size: 829 bytes --]

^ permalink raw reply

* RE: [PATCH] powerpc:Fix rheap alignment problem
From: Li Yang-r58472 @ 2006-07-03  6:49 UTC (permalink / raw)
  To: 'Pantelis Antoniou', Rune Torgersen
  Cc: linuxppc-dev list, Paul Mackerras, linux-kernel

Buddy allocation is good in general, but doesn't mean it fits best in any condition.  In this case for managing DPRAM/MURAM in Freescale soc, in most case we only put buffer descriptor in DPRAM.  That means the alloc/free only occurs on initialization and unloading of the driver.  So there are not supposed to be a lot of free operations.  Buddy allocation will cause more internal fragment, in my humble opinion.  And a free-list allocation is best fit in this case.


Best Regards,
Leo
> -----Original Message-----
> From: linuxppc-dev-bounces+leoli=freescale.com@ozlabs.org
> [mailto:linuxppc-dev-bounces+leoli=freescale.com@ozlabs.org] On Behalf Of
> Pantelis Antoniou
> Sent: Sunday, July 02, 2006 1:18 PM
> To: Rune Torgersen
> Cc: linuxppc-dev list; Paul Mackerras; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH] powerpc:Fix rheap alignment problem
> 
> On Sunday 02 July 2006 06:54, Rune Torgersen wrote:
> > From: Pantelis Antoniou
> > Sent: Sat 7/1/2006 9:50 AM
> > >Since genalloc is the blessed linux thing it might be best to use that &
> remove
> > >rheap completely. Oh well...
> >
> > Two problems with genalloc that I can see (for CPM programming):
> > 1) (minor) Does not have a way to specify alignment (genalloc does it for
> you)
> > 2) (major problerm, at least for me) Does not have a way to allocate a specified
> address in the pool.
> >
> > 2 is needed esp when programming MCC drivers, since a lot of the datastructures
> must be in DP RAM _and_ be in a specific spot. And if you cannot tell the
> allocator that I am using a specific address, then the allocator might very
> well give somebody else that portion of RAM. The only solution without a fixed
> allocator is to allocate ALL memory in the DP RAM and use your own allocator.
> >
> 
> Yeah, that too.
> 
> Too bad there are no main tree drivers like that, but they do exist.
> 
> One could conceivably hack genalloc to do that, but will end up with
> something complex too.
> 
> BTW, there are other uEngine based architectures with similar alignment
> requirements.
> 
> So in conclusion, for the in-tree drivers genalloc is sufficient as an cpm
> memory allocator.
> For some out of tree drivers, it is not.
> 
> Pantelis
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev

^ permalink raw reply

* RE: MPC8548 PCIe / PCI support with BSP MPC8548CDS 02/24/2006
From: Zhang Wei-r63237 @ 2006-07-03  7:54 UTC (permalink / raw)
  To: Florian Boelstler, linuxppc-embedded

Hi, 

> -----Original Message-----
> From: 
> linuxppc-embedded-bounces+wei.zhang=freescale.com@ozlabs.org 
> [mailto:linuxppc-embedded-bounces+wei.zhang=freescale.com@ozla
> bs.org] On Behalf Of Florian Boelstler
> Sent: Monday, July 03, 2006 2:38 PM
> To: linuxppc-embedded@ozlabs.org
> Subject: Re: MPC8548 PCIe / PCI support with BSP MPC8548CDS 02/24/2006
> 
> Hi,
> 
> Zhang Wei-r63237 schrieb:
> > Yes, I think so. You can plug a PCIe ethernet card to test it. 
> 
> A single device always works.
> 
> > :-), Maybe it's need more study. Could you enable the DEBUG 
> and post the kernel verbose message?
> 
> We added lots of debug output and made some modifications 
> (mostly delays between calls to early_read_config_dword() and
> early_write_config_dword() in pci_auto.c) and came to the 
> conclusion that generic bridge devices (PCIe-to-PCI), even in 
> a cascaded setup of three bridges, work fine.

Yea, that's a good news.

> 
> However a PCIe switch (PLX8516/8532) doesn't work. The 
> MPC8548 only detects a single device (i.e. primary side of 
> the switch).
> We are going to analyze the problem more deeply soon. It 
> seems that the configuration space of that devices isn't 
> properly set up.

Just a suggestion.
Do you see below codes in mpc85xx_pex_errata.c(in read and write functions)?
	if (devfn != 0x0) 
		return PCIBIOS_DEVICE_NOT_FOUND;
Change them to:
	if (devfn != 0x0 && bus->number ==0) 
		return PCIBIOS_DEVICE_NOT_FOUND;
And try again. :-)
(If you apply my patch, please use "if (devfn != 0x0 && bus->number ==0xff)" )

> 
> The provided patch doesn't make any difference, besides that 
> it is moved to a location where the PPC itself is not detected.
> 
This patch fix an issue of MPC8641 PCI-Ex controller. It seems MPC8548 has no that issue. Well then fotget it.

Thanks!
Zhang Wei

> Please keep us informed if there is any progress besides 
> Freescale, as I will do.
> 
> Cheers,
> 
>    Florian
> 
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> 

^ permalink raw reply

* Re: Xilinx SystemACE driver for 2.6
From: Ameet Patil @ 2006-07-03  9:05 UTC (permalink / raw)
  To: Grant Likely; +Cc: linuxppc-embedded
In-Reply-To: <528646bc0606301302u5922945dycda569e6954fa353@mail.gmail.com>

Hi Grant,
    I totally agree with you. What you say is correct. It will 
definitely kill the CF card. I use a XUPV2PRO board which doesn't come 
with a microdrive and for my research SWAP is a must. :-)

However, I shall add a NOTE in the article mentioning the same.

Thanks a lot,
-Ameet

Grant Likely wrote:
> On 6/30/06, Ameet Patil <ammubhai@gmail.com> wrote:
>> Here is PART I of the article:
>> http://www.linux.get2knowmore.com/2006/06/30/quick-guide-linux-26-on-xilinx-virtex-ii-pro-boards-part-i/ 
>>
>>
>> Let me know if you get messages at boot time after following the above...
> 
> Quick comment on your article; unless you're using a microdrive;
> *PLEASE* don't recommend using compact flash as swap space.  Flash
> technology has limited write cycles (on the order of 100k to 1M cycles
> per block).  Using it as swap is a great way to kill the lifecycle of
> your device.
> 
> (the ML300 ships with a microdrive; the ML40x ships with a regular CF card)
> 
> I know the previous article also recommends a swap partition, but
> Linux will happily run without swap.
> 
> Cheers,
> g.
> 

^ permalink raw reply

* Re: JFFS2 FS is read-only (not what I want)
From: Mathieu Deschamps @ 2006-07-03 10:42 UTC (permalink / raw)
  To: Ben Warren, linuxppc-embedded
In-Reply-To: <44A6E57A.3080302@qstreams.com>

Hello Ben,

On Saturday 01 July 2006 23:13, Ben Warren wrote:
> Hello,
>
> When I boot from a JFFS2 file system on my eval board, the file system
> is effectively read-only, and I can't figure out why.  I'm pretty sure
> the kernel's configured for R/W MTD block access.  Any help is greatly
> appreciated.
>
Do you mean that you can't even created a void file on / as root ? Else
can you then put for instance text in it ? My point is can or can't you
first create a new fs node and then can you write to file your
changes, that's two possible causes.
>
> The hardware in use is:
>
> Freescale MPC8349EMDS eval board.
> 8MB Q-flash with 64 uniform 128k sectors
>

[...]

> # mount
> /dev/mtdblock4 on / type jffs2 (rw)
> /proc on /proc type proc (rw)
>
[...]
>
> I created the MTD partitions in a u-boot image that was pulled from the

Yes indeed what about drivers/mtd/maps/physmap.c ? your parts are
mask_flags:  MTD_WRITEB_WRITEABLE and not  MTD_CAP_ROM,
aren't they ?

> GIT tree about a week ago, and my kernel is 2.6.17-based.  I wrote some
> board init code that sets the MTD physical mappings.
>
> Here are the MTD and JFFS2 parts of my .config file:
>
> ***
> # Memory Technology Devices (MTD)
> #
> CONFIG_MTD=y
> # CONFIG_MTD_DEBUG is not set
> # CONFIG_MTD_CONCAT is not set
> CONFIG_MTD_PARTITIONS=y
> # CONFIG_MTD_REDBOOT_PARTS is not set
> # CONFIG_MTD_CMDLINE_PARTS is not set
>
[...]
> # CONFIG_JFFS_FS is not set
> CONFIG_JFFS2_FS=y

Better avoid redundacy but this is not a clue, I guess
make won't be fooled by this.

> CONFIG_JFFS2_FS_DEBUG=0
> # CONFIG_JFFS2_FS_WRITEBUFFER is not set
> # CONFIG_JFFS2_SUMMARY is not set
> # CONFIG_JFFS2_COMPRESSION_OPTIONS is not set
> CONFIG_JFFS2_ZLIB=y
> CONFIG_JFFS2_RTIME=y
> # CONFIG_JFFS2_RUBIN is not set
> ***
>
> The file system is the SELF that is included with DENX's ELDK, and built
> as at:
> http://www.denx.de/wiki/view/DULG/RootFileSystemDesignAndBuilding
>
> I used the following command to create the file system image, that was
>
> then loaded at address 0xfe480000 via U-boot:
>  > mkfs.jffs2 -U -d rootfs -D rootfs_device.tab -b -e 0x20000 -o jffs2.img
>

IMHO, it's not a generation-time issue

>
[...]


That's all I have for now. Good luck.


Regards,

Mathieu Deschamps
Com2gether Design Center
Electronic and Embedded Engineering Services
www.com2gether.net 

^ permalink raw reply

* Re: [PATCH] powerpc:Fix rheap alignment problem
From: Benjamin Herrenschmidt @ 2006-07-03 11:08 UTC (permalink / raw)
  To: Pantelis Antoniou; +Cc: linuxppc-dev list, Paul Mackerras, linux-kernel
In-Reply-To: <200607020818.27603.pantelis.antoniou@gmail.com>

On Sun, 2006-07-02 at 08:18 +0300, Pantelis Antoniou wrote:
> On Sunday 02 July 2006 06:54, Rune Torgersen wrote:
> > From: Pantelis Antoniou
> > Sent: Sat 7/1/2006 9:50 AM
> > >Since genalloc is the blessed linux thing it might be best to use that & remove
> > >rheap completely. Oh well...
> > 
> > Two problems with genalloc that I can see (for CPM programming):
> > 1) (minor) Does not have a way to specify alignment (genalloc does it for you)
> > 2) (major problerm, at least for me) Does not have a way to allocate a specified address in the pool.
> > 
> > 2 is needed esp when programming MCC drivers, since a lot of the datastructures must be in DP RAM _and_ be in a specific spot. And if you cannot tell the allocator that I am using a specific address, then the allocator might very well give somebody else that portion of RAM. The only solution without a fixed allocator is to allocate ALL memory in the DP RAM and use your own allocator. 
> > 
> 
> Yeah, that too.
> 
> Too bad there are no main tree drivers like that, but they do exist.
> 
> One could conceivably hack genalloc to do that, but will end up with
> something complex too.
> 
> BTW, there are other uEngine based architectures with similar alignment
> requirements.
> 
> So in conclusion, for the in-tree drivers genalloc is sufficient as an cpm memory allocator.
> For some out of tree drivers, it is not.

Sounds like a good enough justification to keep rheap for now then.

Ben.

^ permalink raw reply

* Re: Problem with Xilinx Uart Lite
From: Qichen Huang @ 2006-07-03 10:59 UTC (permalink / raw)
  To: Andrei Konovalov; +Cc: linuxppc-embedded
In-Reply-To: <44A5178A.5050808@ru.mvista.com>

[-- Attachment #1: Type: text/plain, Size: 1778 bytes --]

Hello Andrei,

Thank you. I have tried this patch, but without luck, the system can not
start, there's no login prompt.
Boot stopps after starting system.
The boot log looks like this:

loaded at: 00400000 004C51E0
board data at: 004C2138 004C2150
relocated to: 0040530C 00405324
zimage at: 00405811 004C1A00
avail ram: 004C6000 04000000

Linux/PPC load: console=ttl0 ip=off root=/dev/xsysace/disc0/part3 rw
Uncompressing Linux...done.
Now booting the kernel
......

Welcome to ML300 powerpc linux 2.4.21, E.I.S. edition

Starting system...
mounting /proc: done.
Mounting '/' read-write: mount: Cannot read /etc/mtab: No such file or
directory

done.
brining up loopback interface: done.
Setup IP-address for eth0: done.
Mounting /tmp: done.
Starting syslogd: done.
Starting klogd: done.
Starting


Thanks,
Qichen

ps. Sorry, I forgot to post this to the mailing list.


On 6/30/06, Andrei Konovalov <akonovalov@ru.mvista.com> wrote:
>
> Seeing a lot of ^M (LF) characters in the end of lines makes me think
> you are using [Win]DOS.
> This makes the patch to look somewhat funny - some of the lines terminated
> with
> <CR> only ("Unix style"), some - with <CR><LF> ("DOS style").
>
> Please try the attached patch. It should help.
>
> Thanks,
> Andrei
>
> Qichen Huang wrote:
> > Hello,
> >
> > attached is my xuartlite_serial.c
> >
> > Thanks,
> > Qichen
> >
> > On 6/30/06, *Andrei Konovalov* <akonovalov@ru.mvista.com
> > <mailto:akonovalov@ru.mvista.com>> wrote:
> >
> >      > Xilinx OS Independent Code XAssert: xuartlite.c:194
> >      > Code may crash due to unhandled errors.
> >
> >     So this is inside XUartLite_Send().
> >     Could you send me your xuartlite_serial.c?
> >     Seems yours doesn't have one of the fixes.
> >
> >     Thanks,
> >     Andrei
>
>
>

[-- Attachment #2: Type: text/html, Size: 2681 bytes --]

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox