LinuxPPC-Dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
* Re: Xilinx Virtex-2 PRO FPGA ppc 405 on ML310 board
From: Grant Likely @ 2006-04-12 21:55 UTC (permalink / raw)
  To: Vincent Winstead; +Cc: linuxppc-embedded list
In-Reply-To: <528646bc0604121450t2467be31med5e97fc14077313@mail.gmail.com>

On 4/12/06, Grant Likely <grant.likely@secretlab.ca> wrote:
> On 4/12/06, Vincent Winstead <vwinstead@yahoo.com> wrote:
>
> >   So, when you say that the "The linuxppc-2.4 tree is
> > special because it's one of the trees that actually has the ML300
> > patches integrated", are you implying that you could put these patches =
into
> > the system on your own if you wanted to?
>
> Of course you can

(assuming of course you can find copies of the patch files)

--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
(403) 399-0195

^ permalink raw reply

* Re: Xilinx Virtex-2 PRO FPGA ppc 405 on ML310 board
From: Grant Likely @ 2006-04-12 21:50 UTC (permalink / raw)
  To: Vincent Winstead; +Cc: linuxppc-embedded list
In-Reply-To: <20060412214613.10018.qmail@web52004.mail.yahoo.com>

On 4/12/06, Vincent Winstead <vwinstead@yahoo.com> wrote:
>
> Very Interesting.  Now I know what they were talking about on the sites t=
hat
> go through how to install the linux kernel onto the ML300.  because in th=
ose
> method  walk-throughs they show which options you should choose when doin=
g a
> "make menuconfig" and there are specific ones regarding Xilinx but I neve=
r
> saw these when doing configurations of what you call mainline versions of
> the linux kernel.

>   So, when you say that the "The linuxppc-2.4 tree is
> special because it's one of the trees that actually has the ML300
> patches integrated", are you implying that you could put these patches in=
to
> the system on your own if you wanted to?

Of course you can

>  You're not talking about the board
> support package are you?

As far as you can apply the concept of BSP to Linux; yes I am.  The
patches provide the code required to work on an ML300 ref design...
drivers and initialization code specifically

g.

--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
(403) 399-0195

^ permalink raw reply

* Re: question about Linux 2.6 with Xilinx ML-403
From: Grant Likely @ 2006-04-12 21:24 UTC (permalink / raw)
  To: Martin, Tim; +Cc: linuxppc-embedded
In-Reply-To: <821B2170E9E7F04FA38DF7EC21DE487104571455@VCAEXCH01.hq.corp.viasat.com>

On 4/12/06, Martin, Tim <tim.martin@viasat.com> wrote:
>
> Which 2.4 driver - there's the "Montavista" one for the softcore PLB
> EMAC, and there's also one for the hardcore PLB TEMAC that gets
> distributed with the GSRD.

The montavista softcore driver.  Has someone written a driver for the TEMAC=
 yet?

g.

--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
(403) 399-0195

^ permalink raw reply

* [10/10]: Quiet oprofile output at boot
From: Olof Johansson @ 2006-04-12 20:29 UTC (permalink / raw)
  To: paulus; +Cc: linuxppc-dev
In-Reply-To: <20060412201823.GG19464@pb15.lixom.net>

No need to always print out which performance monitoring type is used
on the console at every boot.

Signed-off-by: Olof Johansson <olof@lixom.net>


Index: 2.6/arch/powerpc/oprofile/common.c
===================================================================
--- 2.6.orig/arch/powerpc/oprofile/common.c
+++ 2.6/arch/powerpc/oprofile/common.c
@@ -162,7 +162,7 @@ int __init oprofile_arch_init(struct opr
 	ops->stop = op_powerpc_stop;
 	ops->backtrace = op_powerpc_backtrace;
 
-	printk(KERN_INFO "oprofile: using %s performance monitoring.\n",
+	printk(KERN_DEBUG "oprofile: using %s performance monitoring.\n",
 	       ops->cpu_type);
 
 	return 0;

^ permalink raw reply

* [9/10]: Quiet rtasd output at boot
From: Olof Johansson @ 2006-04-12 20:28 UTC (permalink / raw)
  To: paulus; +Cc: linuxppc-dev
In-Reply-To: <20060412201823.GG19464@pb15.lixom.net>

Most users won't really know the difference between a started RTAS
daemon and a missing event-scan. Move it to debug levels.


Signed-off-by: Olof Johansson <olof@lixom.net>


Index: 2.6/arch/powerpc/platforms/pseries/rtasd.c
===================================================================
--- 2.6.orig/arch/powerpc/platforms/pseries/rtasd.c
+++ 2.6/arch/powerpc/platforms/pseries/rtasd.c
@@ -348,7 +348,7 @@ static int enable_surveillance(int timeo
 		return 0;
 
 	if (error == -EINVAL) {
-		printk(KERN_INFO "rtasd: surveillance not supported\n");
+		printk(KERN_DEBUG "rtasd: surveillance not supported\n");
 		return 0;
 	}
 
@@ -440,7 +440,7 @@ static int rtasd(void *unused)
 		goto error;
 	}
 
-	printk(KERN_INFO "RTAS daemon started\n");
+	printk(KERN_DEBUG "RTAS daemon started\n");
 
 	DEBUG("will sleep for %d milliseconds\n", (30000/rtas_event_scan_rate));
 
@@ -487,7 +487,7 @@ static int __init rtas_init(void)
 
 	/* No RTAS */
 	if (rtas_token("event-scan") == RTAS_UNKNOWN_SERVICE) {
-		printk(KERN_INFO "rtasd: no event-scan on system\n");
+		printk(KERN_DEBUG "rtasd: no event-scan on system\n");
 		return 1;
 	}
 

^ permalink raw reply

* [8/10]: Quiet PCI init printouts
From: Olof Johansson @ 2006-04-12 20:26 UTC (permalink / raw)
  To: paulus; +Cc: linuxppc-dev
In-Reply-To: <20060412201823.GG19464@pb15.lixom.net>

Quiet some of the more debug related output from the pci probe routines.

Signed-off-by: Olof Johansson <olof@lixom.net>

Index: 2.6/arch/powerpc/kernel/pci_64.c
===================================================================
--- 2.6.orig/arch/powerpc/kernel/pci_64.c
+++ 2.6/arch/powerpc/kernel/pci_64.c
@@ -605,7 +605,7 @@ static int __init pcibios_init(void)
 	iSeries_pcibios_init(); 
 #endif
 
-	printk("PCI: Probing PCI hardware\n");
+	printk(KERN_DEBUG "PCI: Probing PCI hardware\n");
 
 	/* Scan all of the recorded PCI controllers.  */
 	list_for_each_entry_safe(hose, tmp, &hose_list, list_node) {
@@ -630,14 +630,14 @@ static int __init pcibios_init(void)
 	/* Cache the location of the ISA bridge (if we have one) */
 	ppc64_isabridge_dev = pci_get_class(PCI_CLASS_BRIDGE_ISA << 8, NULL);
 	if (ppc64_isabridge_dev != NULL)
-		printk("ISA bridge at %s\n", pci_name(ppc64_isabridge_dev));
+		printk(KERN_DEBUG "ISA bridge at %s\n", pci_name(ppc64_isabridge_dev));
 
 #ifdef CONFIG_PPC_MULTIPLATFORM
 	/* map in PCI I/O space */
 	phbs_remap_io();
 #endif
 
-	printk("PCI: Probing PCI hardware done\n");
+	printk(KERN_DEBUG "PCI: Probing PCI hardware done\n");
 
 	return 0;
 }
@@ -804,7 +804,7 @@ static pgprot_t __pci_mmap_set_pgprot(st
 	else
 		prot |= _PAGE_GUARDED;
 
-	printk("PCI map for %s:%lx, prot: %lx\n", pci_name(dev), rp->start,
+	printk(KERN_DEBUG "PCI map for %s:%lx, prot: %lx\n", pci_name(dev), rp->start,
 	       prot);
 
 	return __pgprot(prot);
@@ -1212,7 +1212,7 @@ int remap_bus_range(struct pci_bus *bus)
 		return 1;
 	if (start_phys == 0)
 		return 1;
-	printk("mapping IO %lx -> %lx, size: %lx\n", start_phys, start_virt, size);
+	printk(KERN_DEBUG "mapping IO %lx -> %lx, size: %lx\n", start_phys, start_virt, size);
 	if (__ioremap_explicit(start_phys, start_virt, size,
 			       _PAGE_NO_CACHE | _PAGE_GUARDED))
 		return 1;

^ permalink raw reply

* [7/10]: Lack of ISA interrupts on XICS isn't dangerous
From: Olof Johansson @ 2006-04-12 20:26 UTC (permalink / raw)
  To: paulus; +Cc: linuxppc-dev
In-Reply-To: <20060412201823.GG19464@pb15.lixom.net>

This isn't really a dangerous thing any more; most systems lack
ISA interrupt controllers.


Signed-off-by: Olof Johansson <olof@lixom.net>

Index: 2.6/arch/powerpc/platforms/pseries/xics.c
===================================================================
--- 2.6.orig/arch/powerpc/platforms/pseries/xics.c
+++ 2.6/arch/powerpc/platforms/pseries/xics.c
@@ -522,7 +522,7 @@ nextnode:
 
 	np = of_find_node_by_type(NULL, "interrupt-controller");
 	if (!np) {
-		printk(KERN_WARNING "xics: no ISA interrupt controller\n");
+		printk(KERN_DEBUG "xics: no ISA interrupt controller\n");
 		xics_irq_8259_cascade_real = -1;
 		xics_irq_8259_cascade = -1;
 	} else {

^ permalink raw reply

* [6/10]: Less verbose mem configuration output
From: Olof Johansson @ 2006-04-12 20:25 UTC (permalink / raw)
  To: paulus; +Cc: linuxppc-dev
In-Reply-To: <20060412201823.GG19464@pb15.lixom.net>

Quieten some of the debug ram config output. we already print out available
memory at KERN_INFO level.


Signed-off-by: Olof Johansson <olof@lixom.net>


Index: 2.6/arch/powerpc/mm/mem.c
===================================================================
--- 2.6.orig/arch/powerpc/mm/mem.c
+++ 2.6/arch/powerpc/mm/mem.c
@@ -299,9 +299,9 @@ void __init paging_init(void)
 	kmap_prot = PAGE_KERNEL;
 #endif /* CONFIG_HIGHMEM */
 
-	printk(KERN_INFO "Top of RAM: 0x%lx, Total RAM: 0x%lx\n",
+	printk(KERN_DEBUG "Top of RAM: 0x%lx, Total RAM: 0x%lx\n",
 	       top_of_ram, total_ram);
-	printk(KERN_INFO "Memory hole size: %ldMB\n",
+	printk(KERN_DEBUG "Memory hole size: %ldMB\n",
 	       (top_of_ram - total_ram) >> 20);
 	/*
 	 * All pages are DMA-able so we put them all in the DMA zone.
@@ -380,7 +380,7 @@ void __init mem_init(void)
 			totalhigh_pages++;
 		}
 		totalram_pages += totalhigh_pages;
-		printk(KERN_INFO "High memory: %luk\n",
+		printk(KERN_DEBUG "High memory: %luk\n",
 		       totalhigh_pages << (PAGE_SHIFT-10));
 	}
 #endif /* CONFIG_HIGHMEM */
Index: 2.6/arch/powerpc/mm/numa.c
===================================================================
--- 2.6.orig/arch/powerpc/mm/numa.c
+++ 2.6/arch/powerpc/mm/numa.c
@@ -465,9 +465,9 @@ static void __init setup_nonnuma(void)
 	unsigned long total_ram = lmb_phys_mem_size();
 	unsigned int i;
 
-	printk(KERN_INFO "Top of RAM: 0x%lx, Total RAM: 0x%lx\n",
+	printk(KERN_DEBUG "Top of RAM: 0x%lx, Total RAM: 0x%lx\n",
 	       top_of_ram, total_ram);
-	printk(KERN_INFO "Memory hole size: %ldMB\n",
+	printk(KERN_DEBUG "Memory hole size: %ldMB\n",
 	       (top_of_ram - total_ram) >> 20);
 
 	for (i = 0; i < lmb.memory.cnt; ++i)
@@ -485,7 +485,7 @@ void __init dump_numa_cpu_topology(void)
 		return;
 
 	for_each_online_node(node) {
-		printk(KERN_INFO "Node %d CPUs:", node);
+		printk(KERN_DEBUG "Node %d CPUs:", node);
 
 		count = 0;
 		/*
@@ -521,7 +521,7 @@ static void __init dump_numa_memory_topo
 	for_each_online_node(node) {
 		unsigned long i;
 
-		printk(KERN_INFO "Node %d Memory:", node);
+		printk(KERN_DEBUG "Node %d Memory:", node);
 
 		count = 0;
 

^ permalink raw reply

* [5/10]: Don't print chosen idle loop at every boot
From: Olof Johansson @ 2006-04-12 20:23 UTC (permalink / raw)
  To: paulus; +Cc: linuxppc-dev
In-Reply-To: <20060412201823.GG19464@pb15.lixom.net>

No need to write out what idle loop is used on every boot.


Signed-off-by: Olof Johansson <olof@lixom.net>

Index: 2.6/arch/powerpc/platforms/maple/setup.c
===================================================================
--- 2.6.orig/arch/powerpc/platforms/maple/setup.c
+++ 2.6/arch/powerpc/platforms/maple/setup.c
@@ -189,7 +189,7 @@ void __init maple_setup_arch(void)
 	conswitchp = &dummy_con;
 #endif
 
-	printk(KERN_INFO "Using native/NAP idle loop\n");
+	printk(KERN_DEBUG "Using native/NAP idle loop\n");
 }
 
 /* 
Index: 2.6/arch/powerpc/platforms/iseries/setup.c
===================================================================
--- 2.6.orig/arch/powerpc/platforms/iseries/setup.c
+++ 2.6/arch/powerpc/platforms/iseries/setup.c
@@ -535,10 +535,10 @@ static void __init iSeries_setup_arch(vo
 {
 	if (get_lppaca()->shared_proc) {
 		ppc_md.idle_loop = iseries_shared_idle;
-		printk(KERN_INFO "Using shared processor idle loop\n");
+		printk(KERN_DEBUG "Using shared processor idle loop\n");
 	} else {
 		ppc_md.idle_loop = iseries_dedicated_idle;
-		printk(KERN_INFO "Using dedicated idle loop\n");
+		printk(KERN_DEBUG "Using dedicated idle loop\n");
 	}
 
 	/* Setup the Lp Event Queue */
Index: 2.6/arch/powerpc/platforms/powermac/feature.c
===================================================================
--- 2.6.orig/arch/powerpc/platforms/powermac/feature.c
+++ 2.6/arch/powerpc/platforms/powermac/feature.c
@@ -2510,7 +2510,7 @@ found:
 		if (get_property(np, "flush-on-lock", NULL))
 			break;
 		powersave_nap = 1;
-		printk(KERN_INFO "Processor NAP mode on idle enabled.\n");
+		printk(KERN_DEBUG "Processor NAP mode on idle enabled.\n");
 		break;
 	}
 
Index: 2.6/arch/powerpc/platforms/pseries/setup.c
===================================================================
--- 2.6.orig/arch/powerpc/platforms/pseries/setup.c
+++ 2.6/arch/powerpc/platforms/pseries/setup.c
@@ -235,14 +235,14 @@ static void __init pSeries_setup_arch(vo
 	if (firmware_has_feature(FW_FEATURE_SPLPAR)) {
 		vpa_init(boot_cpuid);
 		if (get_lppaca()->shared_proc) {
-			printk(KERN_INFO "Using shared processor idle loop\n");
+			printk(KERN_DEBUG "Using shared processor idle loop\n");
 			ppc_md.power_save = pseries_shared_idle_sleep;
 		} else {
-			printk(KERN_INFO "Using dedicated idle loop\n");
+			printk(KERN_DEBUG "Using dedicated idle loop\n");
 			ppc_md.power_save = pseries_dedicated_idle_sleep;
 		}
 	} else {
-		printk(KERN_INFO "Using default idle loop\n");
+		printk(KERN_DEBUG "Using default idle loop\n");
 	}
 
 	if (firmware_has_feature(FW_FEATURE_LPAR))

^ permalink raw reply

* [4/10]: Quiet VETH version printk
From: Olof Johansson @ 2006-04-12 20:22 UTC (permalink / raw)
  To: paulus; +Cc: linuxppc-dev
In-Reply-To: <20060412201823.GG19464@pb15.lixom.net>

ibmveth_printk() is only used to print the driver version when the module
initializes, which means on all machines as long as it's compiled in.

If it's really only needed for debugging, boot with loglevel=8, or get
it from dmesg instead.

Signed-off-by: Olof Johansson <olof@lixom.net>


Index: 2.6/drivers/net/ibmveth.c
===================================================================
--- 2.6.orig/drivers/net/ibmveth.c
+++ 2.6/drivers/net/ibmveth.c
@@ -61,7 +61,7 @@
 #undef DEBUG
 
 #define ibmveth_printk(fmt, args...) \
-  printk(KERN_INFO "%s: " fmt, __FILE__, ## args)
+  printk(KERN_DEBUG "%s: " fmt, __FILE__, ## args)
 
 #define ibmveth_error_printk(fmt, args...) \
   printk(KERN_ERR "(%s:%3.3d ua:%x) ERROR: " fmt, __FILE__, __LINE__ , adapter->vdev->unit_address, ## args)

^ permalink raw reply

* [3/10]: Quiet page order output
From: Olof Johansson @ 2006-04-12 20:21 UTC (permalink / raw)
  To: paulus; +Cc: linuxppc-dev
In-Reply-To: <20060412201823.GG19464@pb15.lixom.net>

No need to always print page orders.

Signed-off-by: Olof Johansson <olof@lixom.net>


Index: 2.6/arch/powerpc/mm/hash_utils_64.c
===================================================================
--- 2.6.orig/arch/powerpc/mm/hash_utils_64.c
+++ 2.6/arch/powerpc/mm/hash_utils_64.c
@@ -319,7 +319,7 @@ static void __init htab_init_page_sizes(
 		mmu_virtual_psize = MMU_PAGE_64K;
 #endif
 
-	printk(KERN_INFO "Page orders: linear mapping = %d, others = %d\n",
+	printk(KERN_DEBUG "Page orders: linear mapping = %d, others = %d\n",
 	       mmu_psize_defs[mmu_linear_psize].shift,
 	       mmu_psize_defs[mmu_virtual_psize].shift);
 

^ permalink raw reply

* [2/10]: Quiet time init output
From: Olof Johansson @ 2006-04-12 20:20 UTC (permalink / raw)
  To: paulus; +Cc: linuxppc-dev
In-Reply-To: <20060412201823.GG19464@pb15.lixom.net>

Move time_init console output to KERN_DEBUG prink level. No need to
print it at every boot.

Signed-off-by: Olof Johansson <olof@lixom.net>

Index: 2.6/arch/powerpc/kernel/time.c
===================================================================
--- 2.6.orig/arch/powerpc/kernel/time.c
+++ 2.6/arch/powerpc/kernel/time.c
@@ -945,9 +945,9 @@ void __init time_init(void)
 	} else {
 		/* Normal PowerPC with timebase register */
 		ppc_md.calibrate_decr();
-		printk(KERN_INFO "time_init: decrementer frequency = %lu.%.6lu MHz\n",
+		printk(KERN_DEBUG "time_init: decrementer frequency = %lu.%.6lu MHz\n",
 		       ppc_tb_freq / 1000000, ppc_tb_freq % 1000000);
-		printk(KERN_INFO "time_init: processor frequency   = %lu.%.6lu MHz\n",
+		printk(KERN_DEBUG "time_init: processor frequency   = %lu.%.6lu MHz\n",
 		       ppc_proc_freq / 1000000, ppc_proc_freq % 1000000);
 		tb_last_stamp = tb_last_jiffy = get_tb();
 	}

^ permalink raw reply

* [1/10]: Quiet HVSI boot output
From: Olof Johansson @ 2006-04-12 20:19 UTC (permalink / raw)
  To: paulus; +Cc: linuxppc-dev, hollisb
In-Reply-To: <20060412201823.GG19464@pb15.lixom.net>

There's no real need to print the number of found HVSI devices on the
console at every boot.

Signed-off-by: Olof Johansson <olof@lixom.net>

Index: 2.6/drivers/char/hvsi.c
===================================================================
--- 2.6.orig/drivers/char/hvsi.c
+++ 2.6/drivers/char/hvsi.c
@@ -1179,7 +1179,7 @@ static int __init hvsi_init(void)
 	if (tty_register_driver(hvsi_driver))
 		panic("Couldn't register hvsi console driver\n");
 
-	printk(KERN_INFO "HVSI: registered %i devices\n", hvsi_count);
+	printk(KERN_DEBUG "HVSI: registered %i devices\n", hvsi_count);
 
 	return 0;
 }

^ permalink raw reply

* [0/10]: Clean up boot time console messages
From: Olof Johansson @ 2006-04-12 20:18 UTC (permalink / raw)
  To: paulus; +Cc: hollisb, linuxppc-dev

Here's a series of patches that removes a bunch of console messages during PPC
boot. They are moved to KERN_DEBUG instead, which means that:

1. They will still be in dmesg.
2. If needed for debugging, they can be enabled by adding "loglevel=8" to the
boot command line.

But for most uses, I don't see how these messages really add value to the user.
The information is normally available at other places, and mostly needed when
trying to figure out why something doesn't work right.

Since these are all janitorial, I'd appreciate them being queued for 2.6.18.


-Olof

^ permalink raw reply

* RE: question about Linux 2.6 with Xilinx ML-403
From: Martin, Tim @ 2006-04-12 20:15 UTC (permalink / raw)
  To: Grant Likely; +Cc: linuxppc-embedded

> >
> > Ethernet? (Hard-Core PLB TEMAC?, Soft-Core PLB EMAC? Localink TEMAC?
Is
> > 10/100/1000 supported, or is there only 1 rate e.g. 1000 supported?)
>=20
> No.  I've ported the 2.4 driver, but I haven't got permission to
> release it yet.  (I'm a contractor; I don't own any of the work I do)
>=20

Which 2.4 driver - there's the "Montavista" one for the softcore PLB
EMAC, and there's also one for the hardcore PLB TEMAC that gets
distributed with the GSRD.

Thanks,
Tim

^ permalink raw reply

* Re: freescale lite 5200 board and kernel 2.6
From: Matthias Fechner @ 2006-04-12 20:09 UTC (permalink / raw)
  To: linuxppc-embedded
In-Reply-To: <20060410215428.GA22290@raptus.dandreoli.com>

Hello Domenico,

* Domenico Andreoli <cavokz@gmail.com> [10-04-06 23:54]:
> unfortunately it does not :/

im sorry about it, but I'm a newbie too.
The only think I did is documenting how i got the kernel running. :(

> is there any way to force eth0 auto-negotiation?

maybe giving a parameter to the bootargs?
Maybe you found something in the description of the driver in the
kernelconfiguration.

Best regards,
Matthias

^ permalink raw reply

* Re: Xilinx Virtex-2 PRO FPGA ppc 405 on ML310 board
From: Grant Likely @ 2006-04-12 19:52 UTC (permalink / raw)
  To: Vincent Winstead; +Cc: trini, linuxppc-embedded list
In-Reply-To: <20060412193338.75924.qmail@web52010.mail.yahoo.com>

Please remember to CC the mailing list when replying

On 4/12/06, Vincent Winstead <vwinstead@yahoo.com> wrote:
>
>    Now, what does that mean, to get the tree.  Does it mean I'll get a li=
st
> of possible kernels that I can download, and then i'll have to choose one=
 of
> them to download?

It means you get a clone of the source tree + revision history which
you can easily keep up to date with mainline.  For things like Paul's
powerpc and powerpc-merge trees, you need to use it because I don't
think anybody is making .tar.gz snapshots from it.

>    Also, how come I have to go through all this 'git' mumbo-jumbo?  Why
> can't I just go to kernel.org and grab one of the 2.6 kernels off of ther=
e,
> then untar it?  What's so special about the source.mvista.com kernels
> through git and rsync?

If you want to use 2.6:  Git is a pretty easy way to keep up to date
with changes other are making on the tree.  But no, you don't have to
use it.  Some of the maintainers have snapshots generated from their
trees which you can download.

If you use 2.4: You need to use rsync to get the linuxppc-2.4 tree
because I don't think anyone is maintaining .tar.gz of the rsync
snapshot.  Email Tom Rini and ask him.  The linuxppc-2.4 tree is
special because it's one of the trees that actually has the ML300
patches integrated.  Mainline does not.

> --
> Grant Likely, B.Sc. P.Eng.
> Secret Lab Technologies Ltd.
> (403) 399-0195
>
>


--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
(403) 399-0195

^ permalink raw reply

* Re: U-Boot on 440EP Bamboo board, anybody succeed?
From: Wolfgang Denk @ 2006-04-12 19:39 UTC (permalink / raw)
  To: Andriy Korud; +Cc: linuxppc-embedded
In-Reply-To: <60E856FD577CC04BA3727AF4122D3F1601238501@3bit.vector.com.pl>

In message <60E856FD577CC04BA3727AF4122D3F1601238501@3bit.vector.com.pl> you wrote:
> 
> Does anybody succeed to run U-Boot on this board?

Yes, see my reply on the U-Boot list.

Please note thet it is really bad manner to post the same question to
several mailing lists without any indication.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Let's say the docs present a simplified view of reality...    :-)
                      - Larry Wall in  <6940@jpl-devvax.JPL.NASA.GOV>

^ permalink raw reply

* Re: question about Linux 2.6 with Xilinx ML-403
From: Grant Likely @ 2006-04-12 18:46 UTC (permalink / raw)
  To: yding; +Cc: linuxppc-embedded
In-Reply-To: <443D424D.40607@lnxw.com>

On 4/12/06, yding <yding@lnxw.com> wrote:
>  Is this Ethernet device supported by this patch ?

No, sorry.  I'm still trying to get permission to release it (it's
internal only at the moment)

g.

--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
(403) 399-0195

^ permalink raw reply

* Re: question about Linux 2.6 with Xilinx ML-403
From: Grant Likely @ 2006-04-12 18:44 UTC (permalink / raw)
  To: Martin, Tim; +Cc: linuxppc-embedded
In-Reply-To: <821B2170E9E7F04FA38DF7EC21DE4871044F9E54@VCAEXCH01.hq.corp.viasat.com>

On 4/12/06, Martin, Tim <tim.martin@viasat.com> wrote:
> Grant,
>
> I know I could probably figure this out by looking at the GIT tree
> directly (which I'm planning to do) but could you summarize how much
> (which devices) of the ML-403 is supported by your patches?
>
> Serial? (which Xilinx core)
Yes, full uart

>
> Ethernet? (Hard-Core PLB TEMAC?, Soft-Core PLB EMAC? Localink TEMAC? Is
> 10/100/1000 supported, or is there only 1 rate e.g. 1000 supported?)

No.  I've ported the 2.4 driver, but I haven't got permission to
release it yet.  (I'm a contractor; I don't own any of the work I do)

>
> Anything else (GPIO buttons/switches?)
I've got drivers for the PS/2 & VGA, but I'm still trying to get them relea=
sed.

Cheers,
g.

^ permalink raw reply

* Re: Xilinx Virtex-2 PRO FPGA ppc 405 on ML310 board
From: Grant Likely @ 2006-04-12 18:42 UTC (permalink / raw)
  To: Vincent Winstead; +Cc: linuxppc-embedded list
In-Reply-To: <20060412172641.32987.qmail@web52014.mail.yahoo.com>

On 4/12/06, Vincent Winstead <vwinstead@yahoo.com> wrote:
> Thanks for the info!  Now I installed rsync onto this computer with
> configure, then make, then make install and everything seemed to install
> correctly.  Then i typed in:
>
>  rsync rsync://source.mvista.com/linuxppc-2.4
>
>  but it ended up showing a timed-out error message:
>
>  rsync: failed to connect to source.mvista.com: Connection timed out (110=
)
>  rsync error: error in socket IO (code 10) at clientserver.c(107) [receiv=
er]
>
>  Now, I've had problems in the past in that I can't access any ftp server=
s
> due to the fact that I am behind a firewall that I have no control over (=
on
> the University of Minnesota campus) and I was wondering - do you think th=
is
> might be related to that same problem?

You poor sod.  Yes, this is probably the same problem.  You can access
it via http instead.  (the git trees on kernel.org can be accessed
with rsync, http and git protocols.)

BTW, you need to download and install git also (and cogito for a nicer
front end).

http://git.or.cz/

Then you can do a "cg clone <depot>" to get the tree

g.

--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
(403) 399-0195

^ permalink raw reply

* Re: question about Linux 2.6 with Xilinx ML-403
From: yding @ 2006-04-12 18:09 UTC (permalink / raw)
  To: Grant Likely; +Cc: linuxppc-embedded
In-Reply-To: <528646bc0604112104h7bb011abue5eefd9fcbce7fbd@mail.gmail.com>

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

HI, Grant,

I downloaded Paul's git tree as you suggested.

It seems that the defconfig for ML-403(in Patch [9/9]:
http://patchwork.ozlabs.org/linuxppc/patch?id=4226 ), the tri-mode
Ethernet MAC on Virtex-4 FX12 on the ML-403 board was disabled.

Is this Ethernet device supported by this patch ?

Thanks.
--
Ying Ding


Grant Likely wrote:

>On 4/11/06, yding <yding@lnxw.com> wrote:
>  
>
>> I just checked out Linus's GIT tree from
>>rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
>>linux-2.6.
>>
>> Where is the location for Paul's GIT tree ? Just curious ...
>>    
>>
>
>rsync://rsync.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git
>
>g.
>
>--
>Grant Likely, B.Sc. P.Eng.
>Secret Lab Technologies Ltd.
>(403) 399-0195
>
>  
>

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

^ permalink raw reply

* Re: [PATCH 0/6] [RFC] Sizing zones and holes in an architecture independent manner
From: Mel Gorman @ 2006-04-12 17:50 UTC (permalink / raw)
  To: Luck, Tony; +Cc: linuxppc-dev, ak, Linux Kernel Mailing List, bob.picco, davej
In-Reply-To: <20060412163619.GA11085@agluck-lia64.sc.intel.com>

On Wed, 12 Apr 2006, Luck, Tony wrote:

> On Wed, Apr 12, 2006 at 05:00:32PM +0100, Mel Gorman wrote:
>> Patch is attached as 105-ia64_use_init_nodes.patch until I beat sense into
>> my mail setup. I've added Bob Picco to the cc list as he will hit the same
>> issue with whitespace corruption.
>
> Ok!  That boots on the tiger_defconfig.
>
> Some stuff is weird in the dmesg output though.

Ok, I see the problem. It happened because the zone boundary between DMA 
and NORMAL was in a hole.

When I am working out the size of a hole, I check the zone for the end_pfn 
of one active range is the same zone as the start_pfn in the next range. 
In this case, the end of area 1 is 131020 in DMA and the start of area 2 
is 393216 in NORMAL so the hole does not get accounted for.

> You report about
> twice as many pages in each zone, but then the total memory is
> about right.  Here's the diff of my regular kernel (got a bunch of
> patches post-2.6.17-rc1) against a 2.6.17-rc1 with your patches
> applied.  Note also that the Dentry and Inode caches allocated
> twice as much space (presumably based on the belief that there
> is more memory).  My guess is that you are counting the holes.
>
> -Tony
>
> 19,21c20,37
> < On node 0 totalpages: 260725
> <   DMA zone: 129700 pages, LIFO batch:7
> <   Normal zone: 131025 pages, LIFO batch:7
> ---
>> add_active_range(0, 1024, 130688): New
>> add_active_range(0, 130984, 131020): New
>> add_active_range(0, 393216, 524164): New
>> add_active_range(0, 524192, 524269): New
>> Dumping sorted node map
>> entry 0: 0  1024 -> 130688
>> entry 1: 0  130984 -> 131020
>> entry 2: 0  393216 -> 524164
>> entry 3: 0  524192 -> 524269
>> Hole found index 0: 1024 -> 1024
>> Hole found index 1: 130688 -> 130984
>> Hole found index 3: 524164 -> 524192
>> On node 0 totalpages: 522921
>> Hole found index 0: 1024 -> 1024
>> Hole found index 1: 130688 -> 130984
>>   DMA zone: 260824 pages, LIFO batch:7
>> Hole found index 3: 524164 -> 524192
>>   Normal zone: 262097 pages, LIFO batch:7
> 25c41
> < Kernel command line: BOOT_IMAGE=scsi0:EFI\redhat\l-tiger-smp.gz  root=LABEL=/ console=tty1 console=ttyS1,115200 ro
> ---
>> Kernel command line: BOOT_IMAGE=scsi0:EFI\redhat\l-tiger-smpxx.gz  root=LABEL=/ console=uart,io,0x2f8 ro
> 29,30c45,46
> < Dentry cache hash table entries: 524288 (order: 8, 4194304 bytes)
> < Inode-cache hash table entries: 262144 (order: 7, 2097152 bytes)
> ---
>> Dentry cache hash table entries: 1048576 (order: 9, 8388608 bytes)
>> Inode-cache hash table entries: 524288 (order: 8, 4194304 bytes)
> 32c48
> < Memory: 4070560k/4171600k available (6836k code, 99792k reserved, 2749k data, 256k init)
> ---
>> Memory: 4064416k/4171600k available (6832k code, 105936k reserved, 2753k data, 256k init)
>

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab

^ permalink raw reply

* Re: [PATCH 0/6] [RFC] Sizing zones and holes in an architecture independent manner
From: Bob Picco @ 2006-04-12 17:18 UTC (permalink / raw)
  To: Luck, Tony
  Cc: davej, ak, bob.picco, Linux Kernel Mailing List, linuxppc-dev,
	Mel Gorman
In-Reply-To: <20060412170726.GA11143@agluck-lia64.sc.intel.com>

luck wrote:	[Wed Apr 12 2006, 01:07:26PM EDT]
> On Wed, Apr 12, 2006 at 05:00:32PM +0100, Mel Gorman wrote:
> > Patch is attached as 105-ia64_use_init_nodes.patch until I beat sense into 
> > my mail setup. I've added Bob Picco to the cc list as he will hit the same 
> > issue with whitespace corruption.
> 
> Next I tried building a "generic" kernel (using arch/ia64/defconfig). This
> has NUMA=y and DISCONTIG=y).  This crashes with the following console log.
> 
> 
> -Tony
[snip]
Yes. I see the same. It's because with granules we have intersecting
regions which add_active_range doesn't handle. At least that's what
appears to be the reason. I modified add_active_range to combine an
added intersecting region and it boots. However, present pages in zones is
enormous which probably means hole calculation is wrong. That's what I'm
pursuing now.

bob

^ permalink raw reply

* Re: [PATCH 0/6] [RFC] Sizing zones and holes in an architecture independent manner
From: Mel Gorman @ 2006-04-12 17:32 UTC (permalink / raw)
  To: Luck, Tony; +Cc: linuxppc-dev, ak, Linux Kernel Mailing List, bob.picco, davej
In-Reply-To: <20060412170726.GA11143@agluck-lia64.sc.intel.com>

On Wed, 12 Apr 2006, Luck, Tony wrote:

> On Wed, Apr 12, 2006 at 05:00:32PM +0100, Mel Gorman wrote:
>> Patch is attached as 105-ia64_use_init_nodes.patch until I beat sense into
>> my mail setup. I've added Bob Picco to the cc list as he will hit the same
>> issue with whitespace corruption.
>
> Next I tried building a "generic" kernel (using arch/ia64/defconfig). This
> has NUMA=y and DISCONTIG=y).  This crashes with the following console log.
>
>
> <snipped>
> add_active_range(0, 0, 4096): New
> add_active_range(0, 0, 131072): New
> add_active_range(0, 0, 131072): New
> add_active_range(0, 393216, 523264): New
> add_active_range(0, 393216, 523264): New
> add_active_range(0, 393216, 524288): New
> add_active_range(0, 393216, 524288): New

This is where it started going wrong. I did not expect add_active_range() 
to be called with overlapping PFNs so they were not getting merged. If 
they were getting merged correctly, I'd expect the output to be

add_active_range(0, 0, 4096): New
add_active_range(0, 0, 131072): Merging forward
add_active_range(0, 0, 131072): Merging forward
add_active_range(0, 393216, 523264): New
add_active_range(0, 393216, 523264): Merging forward
add_active_range(0, 393216, 524288): Merging forward
add_active_range(0, 393216, 524288): Merging forward

> Virtual mem_map starts at 0xa0007ffffe400000
> Dumping sorted node map
> entry 0: 0  0 -> 131072
> entry 1: 0  0 -> 4096
> entry 2: 0  0 -> 131072
> entry 3: 0  393216 -> 523264
> entry 4: 0  393216 -> 524288
> entry 5: 0  393216 -> 524288
> entry 6: 0  393216 -> 523264
> Hole found index 0: 0 -> 0
> prev_end > start_pfn : 131072 > 0

And here is where it goes BLAM. Without the debugging patch, the check is 
just;

BUG_ON(prev_end_pfn > start_pfn);

The error I was *expecting* to catch was an unsorted node map. It's just 
nice it caught this situation as well. It'll take a while to fix this up 
properly.

Thanks

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab

^ 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