Re: two linux 2.6 kernels on two ppc405 (xupv2p) ?
On Fri, 12 Dec 2008 08:13:26 -0800 (PST) sarah.ddff sarah.d...@gmail.com wrote: Hi all, I want to implement a multiprocessor system managed by a linux kernel on the xupv2p. I knwo that there is no cache coherency between the two ppc405 cores. Consequently, SMP linux can not be used. So the only solution is to install two linux kernels, each on a ppc processor, and to make them communicate with shared memory. My questions are: does someone succeed in doing this? Is it possible to do this ? AMCC has created a dual-460GT board called Arches. I have no idea how it actually works because it faces the same issues a dual-405 board would, but apparently someone must use it somewhere. Basic Arches support is in the kernel, but it's only for a single processor from what I can see. josh ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Weird strings in kernel uname when cross-compiling
On Thu, 04 Dec 2008 12:41:05 +0100 A. Nolson [EMAIL PROTECTED] wrote: Hi all, anybody knows why every time I cross-compile my kernel (Denx 4.2 cross-compiling chain ) I get an extra string in my vermagic like this 2.6.24-rc3-gd7ed933b-dirty when my kernel's ( secretlabs 2.6.24-rc3) makefile has this parameters: VERSION = 2 PATCHLEVEL = 6 SUBLEVEL = 24 EXTRAVERSION = -rc3 (So no -gd7ed933b-dirty anywhere... ) Having that is a bit annoying when I try to natively compile modules, so I need to workaround it by copying that extra string into my other Makefiles. Anybody knows how to get rid of it? It gets added on if you are building from a git repository and you have CONFIG_LOCALVERSION_AUTO set. Disable that and it should go away. (BTW, a quick grep in the top level Makefile would have told you all that.) josh ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: booting 32 bit kernel on G5
On Tue, 4 Nov 2008 11:32:10 -0700 Mitch Crane [EMAIL PROTECTED] wrote: Hi all, First off, I apologize for not searching the archives, I'm afraid the link is broken: http://lists.linuxppc.org/rules.html My AMCC Katmai is on order. In the meantime I'd like to try building and running my driver on my Mac G5 PPC64, running in 32 bit mode. I have a recent YDL distro installed, and can rebuild the kernel, switching off 64 bit in the kernel build config. However, when I try to boot the 32 bit kernel it hangs in the open firmware release keys to continue screen. Can someone please lend a hand here? Has anyone accomplished a 32 bit boot on a Mac G5 with a 2.6 kernel? That support was taken out quite a while ago. It's no longer possible from what I remember. josh ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Build cross compile tool chain for PPC
On Thu, 02 Oct 2008 18:13:49 +0800
åæ [EMAIL PROTECTED] wrote:
Hi, All,
I am a newby for ppc embedded linux. When trying to build the cross compiling
tool
chain, I got some error message in making glibc (binutils and gcc are
successfully
built).
Error message is:
{quote}
assert.c: In function ¡®__assert_fail¡¯:
assert.c:54: error: ¡®__libc_pthread_functions_init¡¯ undeclared (first use in
this function)
assert.c:54: error: (Each undeclared identifier is reported only once
assert.c:54: error: for each function it appears in.)
assert.c:54: warning: implicit declaration of function ¡®PTHFCT_CALL¡¯
assert.c:54: error: ¡®ptr_pthread_setcancelstate¡¯ undeclared (first use in
this
function)
assert.c:54: warning: left-hand operand of comma expression has no effect
make[2]: ***
[/root/embedded_linux/ppc/build-tools/build-glibc/ppc-glibc/assert/assert.os]
Error 1
make[2]: Leaving directory
`/root/embedded_linux/ppc/build-tools/build-glibc/glibc-2.7/assert'
make[1]: *** [assert/subdir_lib] Error 2
make[1]: Leaving directory
`/root/embedded_linux/ppc/build-tools/build-glibc/glibc-2.7'
make: *** [all] Error 2
{quote}
My environments are:
kernel: 2.26. 25
gcc powerpc-linux-gcc: 4.3.2
binutils:2.18
glibc:2.7, configured with linuxthreads enabled and nptl disabled.
glibc 2.7 does not support linuxthreads. It is nptl only. And you
should really be using nptl anyway.
josh
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Tickless and CPU Idle framework for PPC405
On Thu, Sep 25, 2008 at 04:17:54PM +0900, seokin Hong wrote: Generic processor idle management framework http://ols.108.redhat.com/2007/Reprints/pallipadi-Reprint.pdf The interface and machine independent interface is in following directory.. /drivers/cpuidle So, I wonder that the linux kernel ported for PPC405 use this framework to save power. No. PPC4xx doesn't have multiple hardware idle states, so having a govenor to manage that doesn't really make sense. There was work done to support putting the CPU in wait state on idle for PowerPC 440 chips. That could probably be ported over. Beyond that, the cpuidle framework just seems like overkill for these CPUs. And Is the tickless feature is added to that kernel? Tickless was added to all of PowerPC around 2.6.21 or 2.6.22 I think. I don't recall anything explicitly added for 405, but it should make use of the generic support. josh ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: How to use mtdcr from userland code
On Tue, 23 Sep 2008 16:41:49 -0500 Ayman El-Khashab [EMAIL PROTECTED] wrote: Greetings, I am developing an app that needs to map pci address space to the PLB on the ppc460ex. From what I gather I need to use the mtcdr instruction/macro to configure the PIM0 space. However, I cannot figure out how to use that from userland code. Is it possible? Normally, no. The mtdcr/mfdcr instructions are privileged instructions. On that particular core though, there are userspace dcr instructions. They are mtdcrux/mfdcrux instructions documented in the CPU manual. You will have to hard code them, as there are no versions of binutils that I know of that will emit the userspace dcr instructions. Can I change the PIM some other way? Yes, write a proper driver. josh ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Tickless and CPU Idle framework for PPC405
On Thu, Sep 25, 2008 at 06:57:09AM +0900, seokin Hong wrote: Hi, All Is the tickless feature and CPU Idle framework is added in linux tree for PPC405? What CPU Idle framework? josh ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Regarding select() on PPC
On Mon, Sep 22, 2008 at 08:45:52PM +0530, Sadashiiv, Halesh wrote: The issue is found only in PPC32. Please let me if the patch is applicable. Well, no not really. Mostly because of procedural issues than anything else. Read Documentation/SubmittingPatches in the kernel directory. Also, there is a comment above this function that eludes to some issues with select on ppc32. You might want to ask the overall PowerPC maintainer if that issue still exits. josh ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Is there any linux version to support clock and power management(CPM) of PPC405
On Fri, 19 Sep 2008 16:28:09 +0900 __ [EMAIL PROTECTED] wrote: I am searching the linux version to support clock and power management(CPM) of PPC405. Linux kernel use the cpu_idle() function when the cpu don¡¯t have any task to do.. And, the implementation of cpu_idle() is different between each architecture. I cannot find whether latest ppc tree of linux support CPM or not¡¦. It does not. If the official linux support CPM of PPC405, Do Mvista, Red hat, fedora, gentoo support CPM of PPC405? You would have to ask Monta Vista or Wind River if they do. Red Hat, Fedora, and Gentoo don't support PPC405 at all. josh ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Regarding select() on PPC
On Fri, Sep 19, 2008 at 07:00:07PM +0530, Sadashiiv, Halesh wrote: For negetive value of n (first argument to select) select fails with EINVAL error, But for the same when I tested for PowerPC it was giving EFAULT, Its on 2.6.16 kernel. 2.6.16 is really old. I tested your testcase on a 2.6.25 based kernel on a ppc64 machine and it seemed to work fine. josh ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Device Tree
On Tue, Sep 09, 2008 at 05:43:12PM +0200, Georg Schardt wrote: Hi, im searching for informations about the flatten device trees. the only thing i know is, that the device tree is a kind of data-structure which the bios or bootloader gives to the operation system. until now, i boot linux with uboot without a device tree, but newer kernel wants a devicetree, i think ?? i use a virtex4 board with an integrated powerpc how can i create the device tree file ? how must the linux kernel be configured ? is there a good internet page with informations ? In the kernel, look at Documentation/powerpc/booting-without-of.txt You could also read the A Symphony of Flavours: Using the device tree to describe embedded hardware paper on page 27 of: http://www.linuxsymposium.org/2008/ols-2008-Proceedings-V2.pdf josh ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: PPC460EX - Machine check in kernel mode - when accessing I/O in user space
On Tue, Sep 09, 2008 at 04:34:07PM -0700, Henry Bausley wrote:
I am trying to give user space application access to I/O. Previously I
used 2.6.14 with RT Linux and made a kernel device driver with a mmap
routine on a 440EP.
I am converting to a PPC460Ex with 2.6.26-2 with Xenomai the same code
results in a Machine Check in Kernel mode when I attempt to use the code
in user space.
The io memory is in the device tree and with ioremap and I can read and
write to it in kernel mode with
of_address_to_resource(np,0,res)
piom = (unsigned *) ioremap( res.start, RTL_SHIOM_SIZE);
In addition I tried
void *map_base, * virtAddr;
off_t target = ((unsigned int)addr) ~MAP_MASK;
int fd;
if ((fd = open(/dev/mem, O_RDWR | O_SYNC)) == -1) {
printf(/dev/mem could not be opened.\n);
exit(1);
}
/* Map one page */
map_base = mmap((void *)target, length, PROT_READ | PROT_WRITE,
MAP_SHARED, fd, target);
You want mmap2 here. The I/O on 440EPx is above 4GiB.
josh
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: powerpc405 versus powerpc440
On Thu, Sep 04, 2008 at 09:28:01AM -0400, Wood, Robert (GE EntSol, Intelligent Platforms) wrote: We are migrating to the Xilinx Virtex 5 devices and that means migrating our embedded software from the PowerPC405 to PowerPC440. Are there any gotchas we should be aware of, or will this be simple case of S/W migration :-) Erm. 405 and 440 have entirely different MMUs. 405 has real-mode, and 440 is BookE and therefore has the MMU always on. That is mostly an impact to the kernel itself and not to userspace. But it can be annoying if you aren't used to dealing with BookE style CPUs. josh ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: One image for two different core
On Thu, Sep 04, 2008 at 05:18:45PM -0700, Bizhan Gholikhamseh (bgholikh) wrote: Hi All, I am doing a feasibility study whether I can have one image for two different platform with e300 ad e500 core. The idea is uboot will detect which type of the processor is running and pass the information to the early Linux startup, then the code will configure itself based on what type of core it is. That doesn't really sound possible to me with a single kernel binary. If I remember correctly, e300 is a 603e style CPU, and e500 is a BookE CPU. They have totally different MMUs (among other things), which means you would really need to separate kernel binaries to support that. I'm not an Freescale core expert though, so I might be confused or don't know of some way that would work. josh ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: mmap and ppc460gt
On Wed, 27 Aug 2008 20:47:24 -0700
vb [EMAIL PROTECTED] wrote:
On Wed, Aug 27, 2008 at 8:12 PM, Roland Dreier [EMAIL PROTECTED] wrote:
OK, please try this and let me know if it helps:
diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
index 1c93c25..98d7bf9 100644
--- a/arch/powerpc/mm/mem.c
+++ b/arch/powerpc/mm/mem.c
@@ -75,11 +75,10 @@ static inline pte_t *virt_to_kpte(unsigned long vaddr)
int page_is_ram(unsigned long pfn)
{
- unsigned long paddr = (pfn PAGE_SHIFT);
-
#ifndef CONFIG_PPC64 /* XXX for now */
- return paddr __pa(high_memory);
+ return pfn max_pfn;
#else
+ unsigned long paddr = (pfn PAGE_SHIFT);
int i;
for (i=0; i lmb.memory.cnt; i++) {
unsigned long base;
Ronald, thank you for the hint, I actually tried something slightly
different:
return pfn (__pa(high_memory) PAGE_SHIFT);
and it worked. I guess your fix is faster, I'll try it tomorrow.
I also checked that the problem is there in the top of the tree in
Linus' git - isn't it amazing - I guess very few people use mmap()
nowadays, everybody must be using UIO device :-)
No, most people use device drivers in the kernel.
josh
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: 2.6.25: include/asm-ppc vs. include/asm-powerpc
On Thu, Aug 28, 2008 at 10:30:48AM -0400, Paul Smith wrote: On Thu, 2008-08-28 at 15:53 +0200, Arnd Bergmann wrote: The easiest solution should be to just include all your modules in the kernel source as patches, rather than building them externally. That will give you access to all the headers you need. It doesn't matter whether I build my code in the kernel as patches, or not. The problem is not that I don't have the headers handy, it's that they simply don't exist in asm-ppc anymore, not even in the linux source tree. Then you need to adapt your code to where ever that information moved to? Maybe if you post your driver code and makefile we can help you out. There is no asm-ppc/ppc_asm.h in the kernel anymore. In my code that includes it, where ARCH=ppc and include/asm is linked to asm-ppc, how do I get ahold of that file? I can't use #include asm/ppc_asm.h like I used to. Do I have to use #include asm-powerpc/ppc_asm.h explicitly? At least this will work... but read on: Even more troublesome are headers like linux/posix_types.h, which includes asm/posix_types.h, but there IS NO asm-ppc/posix_types.h file in the kernel tree! There is only an asm-powerpc/posix_types.h... but if asm is a link to asm-ppc, this fails and I have no way to fix it! On the other hand, if I cheat and set the asm symlink pointing to asm-powerpc instead, then when I include files like linux/interrupt.h. which includes linux/hardirq.h, which includes asm/hardirq.h, which (because I have CONFIG_40X defined) includes asm/ibm44x.h, I get the opposite problem: there is no asm-powerpc/ibm4xx.h; that header exists only in the asm-ppc directory. So now THAT include fails. This is all confusing to me. Things obviously work in-kernel, or it wouldn't build at all. There used to be a hack in the ppc makefiles to add a -Iasm-powerpc (or a symlink or something) so that files _would_ find the right headers. Look harder at the makefiles and try to duplicate that for your external modules. Or move to the latest git kernel, where this problem doesn't exist at all since arch/ppc is removed entirely :). josh ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH] AMCC PPC460GT/EX PCI-E de-emphasis adjustment fix
On Thu, Aug 21, 2008 at 09:53:34PM -0700, [EMAIL PROTECTED] wrote: From: Tirumala R Marri [EMAIL PROTECTED] During recent tests with PCI-E , it has been found the DRV + De-Emphasis values are not optimum. These new values are tested thouroughly. Signed-off-by: Tirumala R Marri [EMAIL PROTECTED] If you are sending out a patch for someone, you need to include your Signed-off-by as well. Just reply to this with it, no need to resend the just for this. Stefan, this looks good to me. Or at least as far as I can tell from the somewhat magic values :) Any comments? josh ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: New Patchwork beta
On Thu, 2008-08-21 at 15:32 -0500, Kumar Gala wrote: Some feedback: * Can we increase the font size a bit? NOO. Just use CTRL-SHIFT-+. * For the list of patches can we change the background of every other line (light gray) That would work well. * Parsing subject header for determining state -- [RFC] That is going to fail miserably because people tend to do silly things like post final patches in the middle of an [RFC] thread. josh ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Creating a wrapped zImage.initrd -- can't start the trampoline?
On Fri, 2008-08-01 at 22:40 -0400, Paul Smith wrote: Hi all; I'm working with a PPC 460EX-based board. I have a 2.6.25.10-based kernel I obtained from the DENX git tree which contains a port to this board, under arch/powerpc. I can build a kernel and have it downloaded and booting using u-boot, providing the blob and appropriate kernel parameters, after having done a standard make zImage with the appropriate configs etc. All good so far. However, my ultimate target board uses a custom bootloader, not uboot, which is very, very simple (please don't suggest we just switch to uboot--that argument has been already had, and lost :-/) I had a previous version of Linux, 2.6.14, booting on a predecessor of this board based on the 440GX with the same bootloader, but the creation of that image was done under arch/ppc and it was pretty different (I'm discovering). And, I didn't do that port anyway. Anyway, I need to generate an all-in-one image containing the kernel and the initrd, and the trampoline code tacked onto it to turn it into an ELF image. I'm worried I'll need to write a custom platform_init() but for now I'm just using of.c. It needs the vmlinux, dtb, and initrd in a single image. The dtb is required for arch/powerpc ports. From what I can tell, the wrapper script seems to be intended to have the ability to generate an image like this. I've tried just running make zImage.initrd after putting the ramdisk.initrd.gz in the right place, and it seems to create an image OK: using file shows it to be ELF 32-bit MSB executable, PowerPC or cisco 4500, version 1 (SYSV), statically linked, not stripped, which seems correct. But we can't get it to boot. The bootloader downloads the image (tftp) and jumps to the start address in the ELF image, and immediately takes an illegal instruction. We have set the bootloader to load the image at 0x and then we look through the ELF image for the start address, which (using objdump) I can see is the correct address for the _zimage_start symbol from crt0.S; in our case it's 0x00400204. When we use a debugger to look at what's loaded at that location, it's just a whole slew of 0xa bytes... obviously not right. Is the start address not the offset from the start of the ELF image? Should we be loading the image somewhere else (the previous incarnation loaded it at 0x0, so we just did that too)? Load it at the link address. Which is 4MiB. A normal bootloader would have done that. Then the wrapper code will uncompress your kernel to 0x0 for you. josh ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: 4xx USB drivers
On Wed, 2008-07-30 at 13:20 +, - Reyneke wrote: Hi, Does anyone know what the state is of the ppc 44x USB host drivers in the powerpc kernel branch (v2.6.25)? The EHCI and OHCI all seem to be there and OF aware, but we can't quite get it to work. On which 4xx board? I've used OHCI on 440EP with good success. 440EPx has an Errata for OHCI/EHCI interactions. AMCC had a patch for arch/ppc and I believe someone was working on porting that to arch/powerpc (Vitaly maybe?). If you only use one driver at a time, it should work there though. josh ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Writing to CPLD mapped to EBC Port of AMCC440EP
On Mon, 28 Jul 2008 16:40:35 -0700 Henry Bausley [EMAIL PROTECTED] wrote: I am attempting to write to a CPLD mapped to the EBC port of a AMCC 440EP. When I attempt to write using an unsigned variable ie. unsigned *pbase = (unsigned char *)ioremap64(0x8F00,0x100); I get a kernel access of bad area, sig: 11 fault. However, if I change to an unsigned char ie. unsigned char *pbase = (unsigned char *)ioremap64(0x8F00, 0x100); The system doesn't crash. I need to write using an unsigned. Does any one have any ideas what I am doing wrong? The documentation I have for the Bamboo board says the EPLD is at address 0x80002000 and is only 8 bytes in size. Similarly, the Yosemite board CPLD is at 0x80002000 and is only 16 bytes in size. Why you are ioremapping 16MiB at 0x8F00 I have no idea. Also, the individual registers of the EPLD/CPLD on both boards are only 8 bits, so an unsigned char seems appropriate. If you have a custom board that does something totally different from how the eval boards are set up, then I'm not sure many people will be able to help you without documentation for that board. josh ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH] Add AMCC Arches 460GT eval board support to platforms/44x
On Fri, 18 Jul 2008 15:31:33 -0700 (PDT) Victor Gallardo [EMAIL PROTECTED] wrote: From what I can tell, you don't even need this patch or the defconfig. Nothing differs at this point from Glacier other than the DTS. Since U-Boot is your loader, it should be able to pass the different DTS to a kernel that supports Cayonlands and have no issues. ... If you do want to have explicit support for Arches, that's fine. Look at how Yosemite is supported. It just reuses Bamboo. You could do the same. Yes, I like this idea. I'll do this. As you might have noticed, this has generated quite a bit of discussion on whether this is the right approach or not. If you can wait for a week, we plan on talking it over at OLS. Then I can give you a better idea as to whether we're going to stick with this or use a different approach. Overall your patches are fairly clean, so you've done a good job so far. Have a little patience with us as we figure out the right way to go :). josh ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH] Add AMCC Arches DTS
On Tue, 15 Jul 2008 22:34:36 -0700
[EMAIL PROTECTED] wrote:
From: Victor Gallardo [EMAIL PROTECTED]
ppc4xx: Add AMCC Arches DTS
Signed-off-by: Victor Gallardo [EMAIL PROTECTED]
---
arch/powerpc/boot/dts/arches.dts | 522
++
1 files changed, 522 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/boot/dts/arches.dts
diff --git a/arch/powerpc/boot/dts/arches.dts
b/arch/powerpc/boot/dts/arches.dts
new file mode 100644
index 000..459cec2
--- /dev/null
+++ b/arch/powerpc/boot/dts/arches.dts
@@ -0,0 +1,522 @@
+/*
+ * Device Tree Source for AMCC Arches (dual 460GT board)
+ *
+ * (C) Copyright 2008
+ * Victor Gallardo, Applied Micro Circuits Corp., [EMAIL PROTECTED]
+ * Adam Graham, Applied Micro Circuits Corp., [EMAIL PROTECTED]
+ *
+ * Based on the glacier.dts file
+ * Stefan Roese [EMAIL PROTECTED]
+ * Copyright 2008 DENX Software Engineering
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+/ {
Could you convert this to a dts-v1 file please? All the in-tree DTS
files are dts-v1 and I'd very much like to keep it that way.
+ #address-cells = 2;
+ #size-cells = 1;
+ model = amcc,arches;
+ compatible = amcc,arches;
+ dcr-parent = /cpus/[EMAIL PROTECTED];
+
+ aliases {
+ ethernet0 = EMAC0;
+ ethernet1 = EMAC1;
+ serial0 = UART0;
+ serial1 = UART1;
+ };
+
+ cpus {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ [EMAIL PROTECTED] {
+ device_type = cpu;
+ model = PowerPC,460GT;
+ reg = 0;
+ clock-frequency = 0; /* Filled in by U-Boot */
+ timebase-frequency = 0; /* Filled in by U-Boot */
+ i-cache-line-size = 20;
+ d-cache-line-size = 20;
+ i-cache-size = 8000;
+ d-cache-size = 8000;
+ dcr-controller;
+ dcr-access-method = native;
+ };
If this is a dual-460GT, why is there only one CPU node listed? Is it
simply because Linux will only see one CPU as it is an AMP
configuration?
josh
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH] Add AMCC Arches 460GT eval board support to platforms/44x
On Tue, 15 Jul 2008 22:33:26 -0700 [EMAIL PROTECTED] wrote: From: Victor Gallardo [EMAIL PROTECTED] ppc4xx: Add AMCC Arches 460GT eval board support Signed-off-by: Victor Gallardo [EMAIL PROTECTED] From what I can tell, you don't even need this patch or the defconfig. Nothing differs at this point from Glacier other than the DTS. Since U-Boot is your loader, it should be able to pass the different DTS to a kernel that supports Cayonlands and have no issues. --- arch/powerpc/platforms/44x/Kconfig | 18 arch/powerpc/platforms/44x/Makefile |1 + arch/powerpc/platforms/44x/arches.c | 76 +++ 3 files changed, 95 insertions(+), 0 deletions(-) create mode 100644 arch/powerpc/platforms/44x/arches.c diff --git a/arch/powerpc/platforms/44x/Kconfig b/arch/powerpc/platforms/44x/Kconfig index 6abe913..95d1217 100644 --- a/arch/powerpc/platforms/44x/Kconfig +++ b/arch/powerpc/platforms/44x/Kconfig @@ -77,6 +77,16 @@ config CANYONLANDS help This option enables support for the AMCC PPC460EX evaluation board. +config ARCHES + bool Arches + depends on 44x + default n + select 460GT + select PCI + select PPC4xx_PCI_EXPRESS + help + This option enables support for the AMCC PPC460GT Arches board. If you do want to have explicit support for Arches, that's fine. Look at how Yosemite is supported. It just reuses Bamboo. You could do the same. config YOSEMITE bool Yosemite depends on 44x @@ -149,6 +159,14 @@ config 460EX select IBM_NEW_EMAC_ZMII select IBM_NEW_EMAC_TAH +config 460GT + bool + select PPC_FPU + select IBM_NEW_EMAC_EMAC4 + select IBM_NEW_EMAC_RGMII + select IBM_NEW_EMAC_ZMII + select IBM_NEW_EMAC_TAH I don't see a reason to add this at all. 460EX and 460GT select the same set of options. # 44x errata/workaround config symbols, selected by the CPU models above config IBM440EP_ERR42 bool diff --git a/arch/powerpc/platforms/44x/Makefile b/arch/powerpc/platforms/44x/Makefile index 774165f..86a4823 100644 --- a/arch/powerpc/platforms/44x/Makefile +++ b/arch/powerpc/platforms/44x/Makefile @@ -9,3 +9,4 @@ obj-$(CONFIG_RAINIER) += rainier.o obj-$(CONFIG_WARP) += warp.o obj-$(CONFIG_WARP) += warp-nand.o obj-$(CONFIG_CANYONLANDS) += canyonlands.o +obj-$(CONFIG_ARCHES) += arches.o Here you would just have: obj-$(CONFIG_ARCHES) += cayonlands.o diff --git a/arch/powerpc/platforms/44x/arches.c b/arch/powerpc/platforms/44x/arches.c new file mode 100644 index 000..6d6aa66 --- /dev/null +++ b/arch/powerpc/platforms/44x/arches.c And then you don't need this file at all. Just add a amcc,canyonlands string to your root node compatible property. josh ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH] Add AMCC Arches 460GT eval board support to platforms/44x
On Wed, 16 Jul 2008 08:15:39 -0600 Grant Likely [EMAIL PROTECTED] wrote: On Wed, Jul 16, 2008 at 07:50:25AM -0400, Josh Boyer wrote: On Tue, 15 Jul 2008 22:33:26 -0700 [EMAIL PROTECTED] wrote: From: Victor Gallardo [EMAIL PROTECTED] ppc4xx: Add AMCC Arches 460GT eval board support Signed-off-by: Victor Gallardo [EMAIL PROTECTED] From what I can tell, you don't even need this patch or the defconfig. Nothing differs at this point from Glacier other than the DTS. Since U-Boot is your loader, it should be able to pass the different DTS to a kernel that supports Cayonlands and have no issues. --- arch/powerpc/platforms/44x/Kconfig | 18 arch/powerpc/platforms/44x/Makefile |1 + arch/powerpc/platforms/44x/arches.c | 76 +++ 3 files changed, 95 insertions(+), 0 deletions(-) create mode 100644 arch/powerpc/platforms/44x/arches.c diff --git a/arch/powerpc/platforms/44x/Kconfig b/arch/powerpc/platforms/44x/Kconfig index 6abe913..95d1217 100644 --- a/arch/powerpc/platforms/44x/Kconfig +++ b/arch/powerpc/platforms/44x/Kconfig @@ -77,6 +77,16 @@ config CANYONLANDS help This option enables support for the AMCC PPC460EX evaluation board. +config ARCHES + bool Arches + depends on 44x + default n + select 460GT + select PCI + select PPC4xx_PCI_EXPRESS + help + This option enables support for the AMCC PPC460GT Arches board. If you do want to have explicit support for Arches, that's fine. Look at how Yosemite is supported. It just reuses Bamboo. You could do the same. config YOSEMITE bool Yosemite depends on 44x @@ -149,6 +159,14 @@ config 460EX select IBM_NEW_EMAC_ZMII select IBM_NEW_EMAC_TAH +config 460GT + bool + select PPC_FPU + select IBM_NEW_EMAC_EMAC4 + select IBM_NEW_EMAC_RGMII + select IBM_NEW_EMAC_ZMII + select IBM_NEW_EMAC_TAH I don't see a reason to add this at all. 460EX and 460GT select the same set of options. # 44x errata/workaround config symbols, selected by the CPU models above config IBM440EP_ERR42 bool diff --git a/arch/powerpc/platforms/44x/Makefile b/arch/powerpc/platforms/44x/Makefile index 774165f..86a4823 100644 --- a/arch/powerpc/platforms/44x/Makefile +++ b/arch/powerpc/platforms/44x/Makefile @@ -9,3 +9,4 @@ obj-$(CONFIG_RAINIER) += rainier.o obj-$(CONFIG_WARP) += warp.o obj-$(CONFIG_WARP) += warp-nand.o obj-$(CONFIG_CANYONLANDS) += canyonlands.o +obj-$(CONFIG_ARCHES) += arches.o Here you would just have: obj-$(CONFIG_ARCHES) += cayonlands.o diff --git a/arch/powerpc/platforms/44x/arches.c b/arch/powerpc/platforms/44x/arches.c new file mode 100644 index 000..6d6aa66 --- /dev/null +++ b/arch/powerpc/platforms/44x/arches.c And then you don't need this file at all. Just add a amcc,canyonlands string to your root node compatible property. No! Don't do this because it is not true! Meh. You're splitting hairs. It _is_ true from a kernel perspective. Instead, add your board name to canyonlands.c in canyonlands_probe(). It's not the most scalable solution, but it keeps you from lying about your hardware in the .dts file. That could also be done. Frankly though, if you look at the existing board.c files in there now, none of them are special. The device tree really provides the differences these days, not the C code. I'm this || close to just killing them all and doing a 4xx_board.c file that does the right thing based on the few boards that have differences. I'm working on a more scalable solution for this, but for now just add your specific board to canyonlands_probe(). Glad to hear it. Care to share your thoughts? It seems to me that adding board.c files that differ only in board name is pretty silly, so if your solution avoids that I'll be happy. josh ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH] Add AMCC Arches 460GT eval board support to platforms/44x
On Thu, 2008-07-17 at 00:58 +0200, Arnd Bergmann wrote: On Wednesday 16 July 2008, Grant Likely wrote: Shouldn't it be enough to have a common compatible value in each of these boards, e.g. amcc,generic-ppc44x and then just ignore the specific type unless you need to do something special? This is bad for the same reason that amcc,44x-blah compatible values are bad in device nodes. The definition of '*-44x-*' changes over time as new parts are added. Compatible values should always reflect an exact part number. I agree in general, but I also think that all 44x boards should be regarded as the same machine time, in the same way that all powermacs are detected as compatible with Power Macintosh or MacRISC, or how all sorts of serial ports claim compatibility with i8250. For classic SOCs like 4xx or 52xx, the SOC familiy more or less defines the platform, and all the details about peripherals can be expressed in the device tree elsewhere. This is what Grant has done for 52xx and what I was talking about with 4xx_board.c, though 4xx_soc.c is probably a better name. My hesitation is that while it's true today that 440chip name defines the SoC, it might not always be. And the Virtex boards are craziness with the core and FPGA setup. So we need to be careful a bit when chosing what do bind to for generics. If one board is so different that you need a separate board setup in the kernel, it should simply not claim compatibility with the SOC platform. Right. Today we only have a few overrides in 4xx. Namely Canyonlands/Glacier, and Bamboo/Yosemite (Sequoia/Rainier should also really be that way, but they aren't). So if we decide to go to a different scheme, it shouldn't be a big deal to switch. josh ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: PPC to PowerPC Migration
On Wed, 11 Jun 2008 07:38:44 -0700 Darcy Watkins [EMAIL PROTECTED] wrote: Hello, I recently migrated an AMCC PPC405EP system from arch/ppc to arch/powerpc and found that in kernel 2.6.25, my board support patches have reduced to just the board support patches - approx 20k bytes in size (and one small one-line fix needed when using RT Preemption kernel). Compare this with 2.6.24 and earlier where I had to apply patches to complete the PPC405EP and/or arch/powerpc support. Prior to 2.6.23 had to use non kernel.org kernel sources and arch/ppc. 2.6.23 -- patch file size 400k+ 2.6.24 -- patch file size ~80k 2.6.25 -- patch file size ~20k 2.6.26 -- patch file size ~20k I think that with 2.6.25 (and upcoming 2.6.26) this means that 4xx is ready for prime time in arch/powerpc. Did you post your patch for your board port? If not, please do. If so, kindly point me to it so I can look at merging it into mainline? josh ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: PPC to PowerPC Migration
On Wed, 11 Jun 2008 10:15:03 -0700 Darcy Watkins [EMAIL PROTECTED] wrote: Hi Josh, I think it would be more helpful if I were to tidy it a bit and add AMCC Taihu boot support to it first. Then submit it. People are more likely to have access to a Taihu than one of our boards. What I mean by AMCC Taihu boot support is that the board would come up just like our Taihushui/Kolsch family of boards, but would not include the extra drivers, etc needed for USB gadgets, the LCD and other like items that are on the AMCC board. That sounds like a fine plan. If you'd like, you can submit both at the same time (as separate patches). More board ports are always welcome, particularly for stock eval boards. Once I get this done, I can submit BSP patch sets for kernel 2.6.25 and 2.6.26. If there is demand, I could submit a BSP patch set for 2.6.24 as well. Preferably, you'd submit to the tip of the git tree for 4xx. With the pace of kernel development, releasing patches for old kernels just means that someone has to forward port them to the latest tree. That might be a small effort, but in practice it's best to work with bleeding edge if you're going to submit a patch for inclusion. Don't be discouraged by that. There are those that will help you if you run into obstacles. Please send me (or URL to) summarized patch submission instructions / guidelines. The easiest place to start is Documentation/SubmittingPatches in the kernel tree. josh ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: PPC to PowerPC Migration
On Wed, 11 Jun 2008 10:52:13 -0700 Darcy Watkins [EMAIL PROTECTED] wrote: Hi Josh, Is there a special git tree for 4xx or are you referring to kernel.org? ... or do I just post the patches to this list? http://git.kernel.org/?p=linux/kernel/git/jwboyer/powerpc-4xx.git;a=summary You can clone it with: git clone \ git://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/powerpc-4xx.git The 'next' branch contains the current stuff heading into whatever is the next merge window (which right now would be 2.6.27. You can post patches here, but most of them go to the linuxppc-dev list now. josh ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Concern regarding Booting up of linux board ...
On Thu, 5 Jun 2008 01:49:27 -0700 (PDT) Misbah khan [EMAIL PROTECTED] wrote: Hi all .. we are using IMX-31 (ARM Core) processor with Linux 2.6 and redboot as boot loader with jffs2 for NAND flash and facing the concerned problem :- This is the linux powerpc embedded list. I'm sure there are ARM lists somewhere, which can probably help you much more than this one can. josh ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: FP and signal 4
On Wed, 4 Jun 2008 14:43:48 + - Reyneke [EMAIL PROTECTED] wrote: Hi all, Has anyone come across any floating point issues in the new powerpc kernel branch with regards to 44x? I'm seeing programs (i.e. init/busybox) generating signal 4 (illegal instruction) exceptions. If I compile a 2.6.25 kernel with the CONFIG_MATH_EMULATION option set, then everything works OK. I've not seen that. Using a 440EPx (has a onchip FPU) with the ELDK 4.0 ppc_4xxFP toolchain for all apps/kernel/fs. 440EPx should get the FPU enabled at runtime. We use a virtual PVR to do the APU/FPU init. What does your cpu node look like in your DTS file for your board? josh ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Error occured when appended FPGA image in the section of .init.text then bootup
On Sat, 31 May 2008 13:07:53 -0400 David H. Lynch Jr. [EMAIL PROTECTED] wrote: Is there some reason this patch is not getting pushed into mainline ? Lacks Signed-off-by, support for the board in question doesn't even exist in arch/ppc anymore, and arch/ppc is going away in June. josh ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Error occured when appended FPGA image in the section of .init.text then bootup
On Sat, 31 May 2008 14:34:34 -0400 David H. Lynch Jr. [EMAIL PROTECTED] wrote: I do not think the patch in question is board specific. It has been arround for a long time. And I think alot of people have been bitten by the problem. It is required for my board. I think it is required for any board that generates a large enough image. I would be happy to signoff on it - it works/is necescary on my board. You can't sign off on it. It's not your patch. The original author needs to do so. See the text of the Developer's Certificate of Origin 1.1, in Documentation/SubmittingPatches. I really don't think adding this patch is going to do anyone any good when the entire arch/ppc subdirectory is going to be deleted in a week or two. I can not seem to find the same code in arch/powerpc so I have no clue whether something similar might be needed there. That specific code doesn't exist. josh ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: linux powerpc and device trees
On Fri, 23 May 2008 14:53:44 +
- Reyneke [EMAIL PROTECTED] wrote:
memory {
device_type = memory;
reg = ; /* Filled in by zImage */
};
This is where I am unclear as to how to prepare the device tree. Is step (4)
correct since I'm using uImage? Where is the memory information suppose to
come from? Previously U-boot passes this kind of data to the kernel via bd_t
- how does it work now using device trees?
As others have noted, U-Boot can fill in the device tree parts that are
missing if your version of U-Boot is FDT capable. If not, you need to
use a cuImage wrapper to do that part for you. See
arch/powerpc/boot/cuboot-sequoia.c for examples.
josh
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Suitability of patchs as attachments
On Fri, 16 May 2008 09:46:31 +0100 Welch, Martyn (GE EntSol, Intelligent Platforms) [EMAIL PROTECTED] wrote: Hi all, I wish I didn't have to ask this but... For now I'm stuck using Outlook and Exchange for email, despite my best efforts I have been unable to force it to send patchs inline without breaking them (I can get it to do plain text, however it seems to have the habbit of wrapping ling lines, such as the diff --git... lines). Is anyone in the same position and has worked out how to do this? Use gmail. It's free, and as long as you make sure your message is plaintext it won't mess with patches. josh ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: treeImage vs cuImage
On Fri, 2008-05-02 at 07:14 -0700, Darcy Watkins wrote: Hello, I am upgrading my BSP to 2.6.25 and notice cuImage and treeImage. The source files both say Old U-Boot compatibility. That's wrong. treeImage isn't for U-Boot. I should correct that comment. Someone please educate me (or point me to a good URL that explains) as to what the difference is. treeImage is for the older IBM 4xx eval boards that use the simple OpenBIOS ROM monitor. Ebony, Walnut, etc typically came with this firmware. cuImage is for boards using older U-Boot. I want to be able to load the kernel image using an older U-Boot and currently use cuImage for 2.6.23 arch/powerpc (and plain uImage for older kernels under arch/ppc). You want cuImage then. Eventually, I want to generate both an old U-Boot compatible image and a new U-boot compatible image. You'll get this by default when you build for cuImage. The cuImage will contain the vmlinux and the dtb wrapped into a single file for use with older U-Boots. You can just use the vmlinux itself and provide the dtb separately for newer. (I think.) I notice that some boards, the boot support is all in one file, in others, it is split between cuboot-board.c and board.c. In the case of ebony board, I see support for both cuImage and treeImage. Is the strcuture into multiple files to ensure that ebony supports both of these and new U-boot support as well? The boards that are split are for support with multiple different firmwares, or because pieces of those can be shared with different boards. I would like to make my BSP modules lean and clean enough to eventually send back upstream to kernel.org. Great! Also, if there are common snags / pitfalls I need to watch out for switching my BSP and DTS from 2.6.23 to 2.6.25, please warn me. I am using AMCC PPC405EP processor. 405EP should be supported soon. I have a Taihu board, I just need to port it. After that, you should be able to either reuse or mostly copy it. But if you beat me to it, I won't complain at all :) josh ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [U-Boot-Users] AMCC PPC440EPx/sequoia stability question...
On Thu, 2008-04-24 at 06:36 +0200, Stefan Roese wrote: On Thursday 24 April 2008, Josh Boyer wrote: Please note that I recently introduced a CFG_MEM_TOP_HIDE option for the 440EPx CHIP 11 errata. I suggest you take a look at this too and see if this changes your behavior. Explain this a bit more please? Is a kernel change needed here? This depends. When the bootwrapper version is used then yes, the kernel should get changed. This is because the bootwrapper detects the SDRAM size from the DDR2 controller and passes it to Linux. Without bootwrapper no changes are needed, since U-Boot already passes the corrected memory size to Linux (totalsize-4k currently). Hm. Given that AMCC ships the boards with an older U-Boot that requires cuImages, I think we'll need to patch the wrapper. Does 440GRx share this same errata? I would think so. josh ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: simpleboot
On Wed, 2008-04-23 at 15:43 -0400, David H. Lynch Jr. wrote: Grant Likely wrote: make simpleImage.boardname - or - make simpleImage.initrd.boardname The makefile will use arch/powerpc/boot/dts/boardname.dts for the device tree. Thanks, I suspected most of that. But I have not see simpleboot in Linus's tree yet, so I have to back port the patch from the paulus tree and that makes it harder to just try it. simpleboot is in Linus' tree now. It went in with the first pull request paulus sent for .26. I don't understand that comment anyway though. If you're working with a PowerPC board, why aren't you using the powerpc tree (paulus') to begin with? Backporting pieces of it to some other tree seems to be a waste of time to me... josh ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [U-Boot-Users] AMCC PPC440EPx/sequoia stability question...
On Wed, 2008-04-23 at 14:49 +0200, Stefan Roese wrote: On Wednesday 23 April 2008, Dave Littell wrote: At this point all possibilities are on the table and I'm looking for any input from anyone with experience (good, bad, or whatever) with this processor and/or designs similar to the Sequoia. If you scan the U-Boot mailing list for 440EPx/Denali DDR2 problems, you will most likely find some references. Please note that I recently introduced a CFG_MEM_TOP_HIDE option for the 440EPx CHIP 11 errata. I suggest you take a look at this too and see if this changes your behavior. Explain this a bit more please? Is a kernel change needed here? josh ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: simpleboot
On Wed, 2008-04-23 at 22:02 -0400, David H. Lynch Jr. wrote: Josh Boyer wrote: simpleboot is in Linus' tree now. It went in with the first pull request paulus sent for .26. I got it, now to figure it out. I don't understand that comment anyway though. If you're working with a PowerPC board, why aren't you using the powerpc tree (paulus') to begin with? Backporting pieces of it to some other tree seems to be a waste of time to me... I am updating a port I did in 2005 ? based on the ml403 port that was in at that time. But it is an independent BSP. I need to move it to the current powerpc/devicetree, but I have to do so without breaking alot of things we have have working for years. OK... and how does that dictate whether to use Linus' tree or paulus' tree? Both are going to contain roughly the same amount of changes, with the exception that paulus' tree will have more of the PowerPC commits in it, including the Xilinx ml403 stuff from Grant. At the moment I am somewhat surely about a number of the issues related to the powerpc/devicetree migration. Aside from the BSP issues, this breaks my boot monitor, and is going to require adding alot more code than I can either justify or see as necescary because there are some aspects of how the devicetree/powerpc stuff is architected that politely I think are brain dead. I don't mind people calling it brain dead. But if you were being polite, you'd call it brain dead and then actually list the issues so they could be discussed. Others might benefit from that discussion. josh ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Access physical memory via mmap() on ppc440epx.
On Tue, 2008-04-01 at 14:12 -0700, Leonid wrote: Hi: I am trying to read from NOR flash, located on address 0xfc00, on my It's at 0x1fc00 IIRC. TLB entries look strange though. That what it was on u-boot stage: 440EPxtlb 0 10 IDX TID EPN SIZE VTS RPN USER WIMGE USRSVC 0 : 00 4000 256MB V0 - 0_ U: -I-G- XWRXWR 1 : 00 256MB V0 - 0_ U: -I-G- XWRXWR 2 : 00 c000 256MB V0 - 1_c000 U: -I-G- XWRXWR 3 : 00 f000 256MB V0 - 1_f000 U: WI-G- XWRXWR See. Virtual is 0xf000, physical is 0x1f000. On Linux stage it looks rather different: I don't even see your entry in here. Likely because the TLB is small and it's gone by the time you do the dump Probably under MMU it should look this way? How to use mmap() then? Try mmap64 on the real physical address and see if that helps. josh ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: ppc platform for AMCC-440EPx - ELDK to the rescue
On Wed, 26 Mar 2008 15:56:23 -0700 Dave Cogley [EMAIL PROTECTED] wrote: Wolfgang, Could you provide an explanation between the two architectures in the ELDK? I am also using a Sequoia spin off and am trying to determine why I would want to use the powerpc architecture vs. the ppc architecture. arch/ppc is being removed entirely from the kernel.org kernels in June. josh ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: ppc platform for AMCC-440EPx - ELDK to the rescue
On Wed, 26 Mar 2008 09:08:03 -0400 Steve Heflin [EMAIL PROTECTED] wrote: FINALLY the early debugging console output worked, which doesn't work at all using the powerpc platform (and yes, I had the correct port address configured). It should work. It did when the board support was first brought in to arch/powerpc. If it doesn't now, I consider that a regression that needs fixing, at least for Sequoia itself. Looking back at the powerpc platform, I don't see how to disable the Host Bridge initialization without disabling the entire PCI bus. This board does have 2 devices hooked on the PCI bus, just no need for a Host Bridge. As Scott said, how would you talk to any PCI device without the host bridge being configured and enabled? Also, I fail to see what the DTS virtualization layer of the hardware buys us. When debugging, it's so much harder to use than the ppc platform's straight forward and standard methodologies. I can't There are tradeoffs, yes. understand to goal to eliminate the ppc platform, especially given the fact that DENX's ELDK is still using it with Linux 2.6.24.2 !! The ELDK uses both arch/ppc and arch/powerpc. I consider them quite reasonable people, and foresee them eventually switching to arch/powerpc over time. In fact, their efforts are a large part of the continued progress of 4xx on arch/powerpc. josh ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Sequoia build with KDBG
On Fri, 29 Feb 2008 23:02:50 -0600 Olof Johansson [EMAIL PROTECTED] wrote: On Fri, Feb 29, 2008 at 08:30:15PM -0600, Josh Boyer wrote: poor man's debugging works fine if a serial port is available, but my Sequoia platform doesn't get that far! I use u-boot to download and boot my image, and I don't get any serial output after the boot completes: By poking characters out the serial port I meant I literally coded up assembly functions to setup MMU translations and poke hex values at hard coded addresses. That's why it's poor man's. If you had a working serial port out of the box, that would be a luxury ;). Does 4xx have support for udbg and xmon? That would be a good first step in getting an in-kernel debugger facility going. Yes. Or at least it did as of a few kernel releases ago when I last tested it. It's helpful for a number of thing, but debugging extremely early stuff isn't possible with it. josh ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Sequoia build with KDBG
On Fri, 29 Feb 2008 16:34:09 -0500 Steve Heflin [EMAIL PROTECTED] wrote: I attempted to enable the kernel debugger on my Sequoia board, and I get build errors: /linux-2.6.25-rc3/arch/powerpc/kernel/setup_32.c:254: undefined reference to `set_debug_traps' /linux-2.6.25-rc3/arch/powerpc/kernel/setup_32.c:259: undefined reference to `breakpoint' Josh: I assume you have used the kernel debugger with your 44x boards, how did you build it? Why would you assume that? I've never used kgdb on arch/powerpc kernels, nor have I ever tried to build it. I don't think kgdb is ported to powerpc at the moment. josh ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Sequoia build with KDBG
On Fri, 29 Feb 2008 17:31:10 -0500 Steve Heflin [EMAIL PROTECTED] wrote: At 04:35 PM 2/29/2008, Josh Boyer wrote: On Fri, 29 Feb 2008 16:34:09 -0500 Steve Heflin [EMAIL PROTECTED] wrote: I attempted to enable the kernel debugger on my Sequoia board, and I get build errors: /linux-2.6.25-rc3/arch/powerpc/kernel/setup_32.c:254: undefined reference to `set_debug_traps' /linux-2.6.25-rc3/arch/powerpc/kernel/setup_32.c:259: undefined reference to `breakpoint' Josh: I assume you have used the kernel debugger with your 44x boards, how did you build it? Why would you assume that? I've never used kgdb on arch/powerpc kernels, nor have I ever tried to build it. I assumed that because I've always needed a debugger when implementing kernel level components. Since you've implemented kernel level support for several 44x processors, I just assumed that you needed kdbg at some point. So you're saying that your additions Nope. I did the poor man's method of manually poking characters out of the serial port. worked right out of the gate and you never needed a debugger? You're my hero! I largely stood on the shoulders of those that came before me. Porting has become trivial lately, mostly due to the collective work lots of people have put in. That all being said, I'm not opposed to having kgdb work on 4xx. I just have never personally looked at it yet. Patches welcome :). josh ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Sequoia build with KDBG
On Fri, 29 Feb 2008 19:23:40 -0500 Steve Heflin [EMAIL PROTECTED] wrote: Putting the list back on CC because I'm sure you won't be the only person to have this issue. poor man's debugging works fine if a serial port is available, but my Sequoia platform doesn't get that far! I use u-boot to download and boot my image, and I don't get any serial output after the boot completes: By poking characters out the serial port I meant I literally coded up assembly functions to setup MMU translations and poke hex values at hard coded addresses. That's why it's poor man's. If you had a working serial port out of the box, that would be a luxury ;). = bootm 0x50 ## Booting image at 0050 ... Image Name: Kernel and Ramdisk Created: 2008-03-01 0:09:57 UTC Image Type: PowerPC Linux Multi-File Image (gzip compressed) Data Size:2430248 Bytes = 2.3 MB Load Address: Entry Point: Contents: Image 0: 1471523 Bytes = 1.4 MB Image 1: 958712 Bytes = 936.2 kB Verifying Checksum ... OK Uncompressing Multi-File Image ... OK Loading Ramdisk to 07e42000, end 07f2c0f8 ... OK -- console port is now dead. -- What image type are you using? If this is an older U-Boot, you'll need to use the cuImage.sequoia file that is produced when you compile your kernel with 'make zImage'. Sequoia (and I'm assuming you mean the AMCC Sequoia Eval Board, not some custom hardware that's based on it) has been working fine for a long time. It seems you have some kind of other uImage, so try using the one that's built with the kernel and go from there. josh ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: MODPOST section mismatches
On Fri, 22 Feb 2008 11:12:47 -0500 Steve Heflin [EMAIL PROTECTED] wrote: To reproduce the problem and see the details on section mismatches: make ARCH=powerpc sequoia_defconfig make ARCH=powerpc CONFIG_DEBUG_SECTION_MISMATCH=y All of those warnings are in drivers or common code. And yes, they should eventually all be fixed. After modifying the make launch to include the recommended option shown above, I see that the section mismatch warning is due to data structures containing the address of initialization modules which have the __init attribute. Since the memory model is FLAT, is this a problem? What do you mean by the memory model is FLAT? josh ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: MODPOST section mismatches
On Fri, 22 Feb 2008 17:26:52 -0500 Steve Heflin [EMAIL PROTECTED] wrote: FLAT_MEM is one of the configuration options: CONFIG_ARCH_FLATMEM_ENABLE=y That has to do with NUMA stuff. It really doesn't have much bearing on the section warnings. josh ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Sample driver
On Tue, 19 Feb 2008 20:13:24 -0800 (PST) Silwer star [EMAIL PROTECTED] wrote: Does anyone have sample drivers in Linux for the EBC interface for PPC405Ex? I would be thankful if someone could put in a sample code here. Linux typically doesn't touch the EBC itself. That is normally set up by firmware such as U-Boot and Linux uses it as-is. josh ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Ethernet breakdown on a Yosemite evaluation board
On Tue, 19 Feb 2008 14:00:19 +0100 Nicolas Genevrier [EMAIL PROTECTED] wrote: Hello all, I noticed an Ethernet blocking on a Yosemite evaluation board when we are using both Ethernet devices (eth0 and eth1). To reproduce the issue, I just telnet the board from a PC (PC1) through eth0 and then telnet another PC (PC2) from the first telnet session through eth1. Then I display a lot of characters on the last telnet session: $ for i in `seq 1 10`; do echo $i aaa..(x160)..aaa; done After a while, transmission is blocked and leads to an rxde interruption from the MAL. Yosemite evaluation kit runs Linux 2.16.13 but I reproduced the issue with our board running Linux-2.6.16 on a 440EP. In Linux 2.6.16, the new ibm_emac driver tries to recover the error but Ethernet remains very very slow even one day after the end of the transmission. I didn't notice any evolution related to this neither any discussion on the topic. Sorry if I missed them. I am working on the subject but an idea or related information would be helpful. There was a patch from Wolfgang Ocker recently that fixed some interrupt settings for 440EP in arch/ppc. You might want to look at that. I still need to evaluate if the arch/powerpc port needs fixing. http://patchwork.ozlabs.org/linuxppc/patch?person=1210id=16789 josh ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Ethernet breakdown on a Yosemite evaluation board
On Tue, 19 Feb 2008 16:04:35 +0100 Nicolas Genevrier [EMAIL PROTECTED] wrote: Thanks a lot for the information, I apologize having not seen the posted patch. Everything seems to run well now. No worries. It was a recent patch and not on this list even, so no need to apologize. Glad things are working for you. josh ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: 2.6.24 for mpc8458amc
On Tue, 19 Feb 2008 11:53:02 -0600 Scott Wood [EMAIL PROTECTED] wrote: maxime louvel wrote: Hi again, this time I have tried to compile the kernel, with an embedded compiler on the board. here is the result... BOOTAS arch/powerpc/boot/ps3-hvcall.o BOOTCC arch/powerpc/boot/ps3.o BOOTCC arch/powerpc/boot/treeboot-bamboo.o BOOTCC arch/powerpc/boot/cuboot-8xx.o BOOTCC arch/powerpc/boot/cuboot-pq2.o BOOTCC arch/powerpc/boot/cuboot-sequoia.o BOOTCC arch/powerpc/boot/treeboot-walnut.o Assembler messages: Error: Internal assembler error for instruction icbt Internal error, aborting at ../../gas/config/tc-ppc.c line 1300 in ppc_setup_opcodes Please report this bug. make[2]: *** [arch/powerpc/boot/treeboot-walnut.o] Error 2 make[1]: *** [uImage] Error 2 make: *** [sub-make] Error 2 That's a bug in older toolchains, which is aggravated by a misguided policy that we build all wrapper platforms, always. Either use a newer toolchain, or remove treeboot-walnut from arch/powerpc/boot/Makefile. It would be good to know what versions of binutils and gcc are being used though. josh ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Sequoia NAND
On Sun, 17 Feb 2008 06:39:43 -0500 Steve Heflin [EMAIL PROTECTED] wrote: I don't see where the new powerpc architecture and drivers/mtd/nand contains support for the NAND chip on the Sequoia platform. We have It's not. Is the Sequoia's NAND Flash Controller supported in the current Linux-2.6.25? No. There are a couple different patches floating around for it, all of which need work. The driver is drivers/mtd/nand/ndfc.c and work needs to be done to parse a device tree and present the proper platform devices so that driver will work. Stefan has something like this somewhere, I've just been lax in getting it into my tree. Too late for .25, but I have 4 boards that use this now so I'll be a bit more interested in getting it into .26. josh ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Sequoia NAND - others missing?
On Sun, 17 Feb 2008 10:27:22 -0500 Steve Heflin [EMAIL PROTECTED] wrote: Are there other devices (beside the NAND Flash Controller) that exist on the AMCC-440EPx chip and are not supported by the current Linux-2.6.25 ARCH=powerpc? i2c, GPIO, the security stuff (if your version has that), and GPT. Thought GPT has never really been supported in any kernel that I remember. Patches for i2c and GPIO are floating around somewhere I think. Just need to get them polished up and device-tree compliant. josh ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Ebony development board
On Mon, 11 Feb 2008 07:20:12 +0100 Stefan Roese [EMAIL PROTECTED] wrote: Hi Zoltan, On Saturday 09 February 2008, Zoltan HERPAI wrote: I've recently got an Ebony board (440GP) with the original bootloader (440GP 1.18 ROM Monitor) which I would like to replace with U-boot. Is there a way to boot an U-boot image via TFTP to replace the bootloader, or is it possible only with using a JTAG? I've googled through the mailing list, but most of the related hits are dated back in 2004-2005, they say no, one have to use JTAG, but some time passed since then, and I would like to know if there is a way for this. Does the original ROM monitor support writing to onboard FLASH? If yes, it should be possible. It doesn't. Theoretically, you can boot Linux and use MTD on the flash to load U-Boot. I wouldn't recommend it without a JTAG debugger around to fix things in case they get screwed up. josh ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Reminder: removal of arch/ppc
On Thu, 31 Jan 2008 15:54:46 -0700 Mark A. Greer [EMAIL PROTECTED] wrote: On Fri, Jan 25, 2008 at 10:55:25AM -0600, Kumar Gala wrote: Just a reminder that the plan is to remove arch/ppc this summer (June 2008). The following boards still existing over in arch/ppc. Some of them have been ported over to arch/powerpc. If you care about one of these boards and its not ported speak up (it helps if you have access to the board). Also, if you know a given board is free to die of bitrot let us know so we know not to worry about it: I guess I'm just not a nice guy but I say let them die. No need to worry. The code really isn't going anywhere -- git-checkout v2.6.pick your favorite version and its back. You're a nice guy. You just aren't as much of a masochist as the rest of us I guess. ;) josh ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: build is broken
On Fri, 1 Feb 2008 15:23:21 -0800 Bizhan Gholikhamseh (bgholikh) [EMAIL PROTECTED] wrote: Hi I just downloaded the latest source tree from : git://www.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git I am using gnu cross compiler version 3.4.3. I get the an awk and assmbeler error. Please help me out. Thanks $ mailto:[EMAIL PROTECTED] make ARCH=powerpc CROSS_COMPILE=powerpc-linux-gnu- uImage awk: cmd. line:1: (FILENAME=- FNR=2) fatal: attempt to access field -1 CHK include/linux/version.h CHK include/linux/utsrelease.h CALLscripts/checksyscalls.sh CHK include/linux/compile.h CALLarch/powerpc/kernel/systbl_chk.sh LD vmlinux.o MODPOST vmlinux.o WARNING: vmlinux.o(.meminit.text+0x9f8): Section mismatch in reference from the function free_area_init_node() to the function .init.text:__alloc_bootmem_node() The function __meminit free_area_init_node() references a function __init __alloc_bootmem_node(). If free_area_init_node is only used by __alloc_bootmem_node then annotate free_area_init_node with a matching annotation. AS .tmp_kallsyms2.o LD vmlinux SYSMAP System.map SYSMAP .tmp_System.map BOOTCC arch/powerpc/boot/treeboot-walnut.o Assembler messages: Error: Internal assembler error for instruction icbt Internal error, aborting at /usr/src/RPM/BUILD/crosstool/source/binutils-2.15/gas/config/tc-ppc.c line 1300 in ppc_setup_opcodes Please report this bug. make[1]: *** [arch/powerpc/boot/treeboot-walnut.o] Error 2 make: *** [uImage] Error 2 I have no idea why you would get that if you have a properly built toolchain. Can you do a fresh compile with V=1 set? josh ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Haleakala Defconfg
On Tue, 29 Jan 2008 14:05:41 -0800 Grant Erickson [EMAIL PROTECTED] wrote: Is there a patch pending to for 'arch/powerpc/configs/haleakala_defconfig'? Not to my knowledge. I did not see one in either of: git://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/powerpc-4xx.git git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git If no patch is pending, to whom do I submit such a patch? It'll simply be a near clone of 'kilauea_defconfig', save the CONFIG_DEVICE_TREE entry. Send one to me. CC Stefan Roese please. josh ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH] 4xx: Clone haleakala_defconfig from kilauea_defconfig
On Tue, 29 Jan 2008 14:49:59 -0800 Grant Erickson [EMAIL PROTECTED] wrote: On 1/29/08 2:09 PM, Josh Boyer wrote: On Tue, 29 Jan 2008 14:05:41 -0800 Grant Erickson [EMAIL PROTECTED] wrote: Is there a patch pending to for 'arch/powerpc/configs/haleakala_defconfig'? Not to my knowledge. I did not see one in either of: git://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/powerpc-4xx.git git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git If no patch is pending, to whom do I submit such a patch? It'll simply be a near clone of 'kilauea_defconfig', save the CONFIG_DEVICE_TREE entry. Send one to me. CC Stefan Roese please. josh * Allow for 'make haleakala_defconfig' by providing a default configuration for the AMCC PowerPC 405EXr Haleakala board. As silly as it sounds, I need a Signed-off-by for this. Could you read Documentation/SubmittingPatches section 12 and just reply to this with a Signed-off-by line? josh ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH] 4xx: Clone haleakala_defconfig from kilauea_defconfig
On Tue, 29 Jan 2008 17:12:09 -0700 Grant Likely [EMAIL PROTECTED] wrote: On 1/29/08, Josh Boyer [EMAIL PROTECTED] wrote: On Tue, 29 Jan 2008 16:22:52 -0700 Grant Likely [EMAIL PROTECTED] wrote: Rather than adding more defconfigs, can we have a single defconfig for 440 and another one for 405? The configs directory is getting a bit silly. You mean mulitplatform kernels? Or what do you mean? Yes, multiplatform kernels. Per IRC, I need patches or time ;) josh ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Help: I will port amcc yucca board to denx kernel ARCH=powepc directory.How to config dts file?
On Tue, 29 Jan 2008 16:11:35 -0800 (PST) jie han [EMAIL PROTECTED] wrote: Hi all, I want to port amcc yucca board denx linux kernel from ARCH=ppc to ARCH=powerpc. I used sequoia.dts for yucca baord demo device tree file. I would start with the Katmai DTS instead. It's at least the same CPU type. josh ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Preferred GIT URL for arch/powerpc Latest-and-Greatest (was Re: Reminder: removal of arch/ppc - (Sequoia))
On Mon, 28 Jan 2008 09:01:12 -0800 Grant Erickson [EMAIL PROTECTED] wrote: On 1/27/08 6:00 PM, Josh Boyer wrote: On Sun, 27 Jan 2008 18:37:22 -0500 Steve Heflin [EMAIL PROTECTED] wrote: Hello! Yes! I'm looking at 2.6.23.14 as I thought that was the newest version. I completely missed seeing the 2.6.24 kit, thank you so much!! FYI, 2.6.24 is considered fairly old relatively speaking. With so much activity going on for the embedded boards for arch/powerpc, you're sort of missing out if you aren't running from the latest git trees. Yes, I realize how ridiculous it sounds to say a kernel that was just released 3 days ago is old, but that's reality. josh What's the best/preferred GIT URL for current, up-to-date arch/powerpc activity? Is it? git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc Yep, that's the canonical source. I am particularly interested in Kilauea/Haleakala-related development. My tree: git://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/powerpc-4xx.git might briefly have some stuff for those that Paul's doesn't at times, but as of right now they are synced up. Typically there are only changes on the next kernel branch during the development period for that particular version. josh ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Preferred GIT URL for arch/powerpc, and BINUTILS
On Mon, 28 Jan 2008 17:46:47 -0500 Steve Heflin [EMAIL PROTECTED] wrote: At 02:30 PM 1/28/2008, Steve Heflin wrote: Josh, you're a life saver!! Your GIT tree is exactly what I've been looking for. I have an AMCC440EPx based product that makes heavy use of all the devices embedded in the microcontroller. I'll be able to give that platform a very good testing. Now can you help me with BINUTILS? What version do you use and can you point me to a decent GIT tree for it? I tried to use version 2.18 and the build blows up because it tries to strip a script file embedspu. Whoa! I spoke too soon. Upon attempting a make menuconfig on the 2.6.24-rc8 which I cloned from your git tree, I don't even SEE the powerpc architecture appearing! What's up? I dunno. I never use make menuconfig. I typically do: make ARCH=powerpc sequoia_defconfig or something similar if I'm cross-building from x86. Otherwise if I'm on the G5, it's just: make sequoia_defconfig josh ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Preferred GIT URL for arch/powerpc, and BINUTILS
On Mon, 28 Jan 2008 19:43:52 -0600 Josh Boyer [EMAIL PROTECTED] wrote: On Mon, 28 Jan 2008 17:46:47 -0500 Steve Heflin [EMAIL PROTECTED] wrote: At 02:30 PM 1/28/2008, Steve Heflin wrote: Josh, you're a life saver!! Your GIT tree is exactly what I've been looking for. I have an AMCC440EPx based product that makes heavy use of all the devices embedded in the microcontroller. I'll be able to give that platform a very good testing. Now can you help me with BINUTILS? What version do you use and can you point me to a decent GIT tree for it? I tried to use version 2.18 and the build blows up because it tries to strip a script file embedspu. Whoa! I spoke too soon. Upon attempting a make menuconfig on the 2.6.24-rc8 which I cloned from your git tree, I don't even SEE the powerpc architecture appearing! What's up? I dunno. I never use make menuconfig. I typically do: make ARCH=powerpc sequoia_defconfig or something similar if I'm cross-building from x86. Otherwise if I'm on the G5, it's just: make sequoia_defconfig Oh, and that's on the for-2.6.25 branch of my tree. I'll update the master soon-ish to match the powerpc git tree. josh ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Reminder: removal of arch/ppc - (Sequoia)
On Sun, 27 Jan 2008 18:37:22 -0500 Steve Heflin [EMAIL PROTECTED] wrote: Hello! Yes! I'm looking at 2.6.23.14 as I thought that was the newest version. I completely missed seeing the 2.6.24 kit, thank you so much!! FYI, 2.6.24 is considered fairly old relatively speaking. With so much activity going on for the embedded boards for arch/powerpc, you're sort of missing out if you aren't running from the latest git trees. Yes, I realize how ridiculous it sounds to say a kernel that was just released 3 days ago is old, but that's reality. josh ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Reminder: removal of arch/ppc
On Sat, 26 Jan 2008 10:09:25 +0100 Zoltan HERPAI [EMAIL PROTECTED] wrote: Kumar Gala wrote: 4xx: EBONY I have an Ebony at hand, so if no one takes it, I'll give it a try to port it over. It's ported. It was the first 4xx board to be ported. Thanks for offering though! josh ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Reminder: removal of arch/ppc
On Fri, 25 Jan 2008 20:07:57 -0700 Grant Likely [EMAIL PROTECTED] wrote: On 1/25/08, Kumar Gala [EMAIL PROTECTED] wrote: Just a reminder that the plan is to remove arch/ppc this summer (June 2008). I strongly recommend that we delay removal by about a month... somewhere around July 23-26... so we can have a great big ding, dong, arch/ppc is dead party at OLS. Ironically, that is where the original June date came from. Segher suggested doing it at OLS, which for some reason we all thought was in June. But this is Linux. We never do anything on time, so I'm sure it'll work out ;) josh ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Reminder: removal of arch/ppc
On Fri, 25 Jan 2008 17:30:32 -0800 Roland Dreier [EMAIL PROTECTED] wrote: YUCCA Yucca was what again? 440spe? Yes, it was the first 440SPe eval board; since replaced by Katmai. I have a Yucca and can at least test thing; if no one else gets to it, I may try to port it to arch/powerpc for 2.6.26. Hm. Katmai is already in-tree. Theoretically I should be able to get the HW docs and do a new DTS and have it mostly just work. Perhaps I'll give that a shot and have you give it a quick spin. josh ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Reminder: removal of arch/ppc
On Fri, 25 Jan 2008 10:55:25 -0600 Kumar Gala [EMAIL PROTECTED] wrote: Just a reminder that the plan is to remove arch/ppc this summer (June 2008). The following boards still existing over in arch/ppc. Some of them have been ported over to arch/powerpc. If you care about one of these boards and its not ported speak up (it helps if you have access to the board). Also, if you know a given board is free to die of bitrot let us know so we know not to worry about it: 4xx: BAMBOO Ported (mostly) CPCI405 Doubt this will be ported. EBONY Ported (mostly) EP405 Ported (mostly) BUBINGA LUAN No idea on these. YUCCA Yucca was what again? 440spe? OCOTEA This one will be ported soon. I have an ocotea now. REDWOOD_5 REDWOOD_6 Don't have either of these. SYCAMORE I think Mathias was working on a 405gpr port somewhere. TAISHAN WALNUT Ported (mostly) XILINX_ML300 XILINX_ML403 Grant should have these in decent shape. josh ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: USB device for ppc440epx
On Wed, 23 Jan 2008 17:01:02 -0800 Leonid [EMAIL PROTECTED] wrote: Hi: does somebody have code example for USB 2.0 device implementation for ppc440epx, preferably Mass Storage device, but any will do. If not for ppc440epx (Sequoia board), ppc440ep (Yosemite) code will also help (according to CPU user manual USB device interface is practically the same). If this is already present in Linux kernel tree (from what version?), where it is located? USB mass storage works on 440EP already. It'll be in 2.6.25 in arch/powerpc. I would suspect 440EPx works as well. BTW, it's considered impolite to hijack a thread to ask a completely unrelated question. josh ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: framebuffer swap endianess
On Tue, 22 Jan 2008 16:46:47 +0100 (CET) Angelo [EMAIL PROTECTED] wrote: Hi, i'm angelo. I have just create a framebuffer for an embedded system: - powerpc (little endian) with a GPU (big endian). I think you have those backwards? PowerPC is big-endian... josh ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Problems with serial and DHCP when booting from NFS
On Tue, 15 Jan 2008 00:09:52 -0800 [EMAIL PROTECTED] wrote: Hi all, I am porting a MontaVista Linux for PPC405 and encountering some problems. I hope someone can help me find it out. You didn't say what kernel you're using, or what you're porting to (arch/ppc or arch/powerpc). 1. About the serial port. I have solved this problem, but I don't know why. If I set Initial Kernel Command String as console=ttyS0,19200 ip=on nfsroot=[my_nfsroot] rw, after outputing Now booting the kernel in the booting process, the booting kernel seems hanging there. In fact, when I checked the log of DHCP server, I found the PPC had already sent DHCP requests. It can be infered that the kernel had been booted but serial had something wrong, so no other information was output after Now booting the kernel. If I set Initial Kernel Command String as ip=on nfsroot=[my_nfsroot] rw, the booting information will appear on the terminal window correctly after Now booting the kernel. I don't know why. I use Uart Lite and the baud rate is 19200. uartlite doesn't show up as ttyS0 IIRC, so your initial console setting was wrong. 2. About the DHCP. The kernel is boot from NFS, so I enabled the DHCP. From the information on terminal window, I knew that DHCP requests were always time out and the client kept retrying. But when I checked the log of DHCP server, I found the server had already offered IP to the client kernel. It seems the client kernel has some problem to receive the DHCP offer, has anyone encountered similar problems? How to solve this problem? I've seen that on a board I have. Haven't debugged it yet because I had to unhook everything to paint the room it was in. I think it's something to do with an initialization race in the EMAC driver or some other place. josh ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: How to config linux kernel(ARCH=powerpc)?
On Tue, 8 Jan 2008 09:18:23 +0800 tony [EMAIL PROTECTED] wrote: hi Jie maybe you should try it like this: linux-2.6-denx-make ARCH=ppc CROSS_COMPILE=ppc_4xx- pasemi_defconfig make sure you have installed the ppc_4xx- tools. Um.. no. pasemi is a 64bit CPU. Get the powerpc tree from kernel.org, make sure you have a PowerPC 64bit toolchain, and try with make ARCH=powerpc josh ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: How is a device tree used to specifiy flash?
On Thu, 13 Dec 2007 15:28:37 -0800
[EMAIL PROTECTED] wrote:
Okay I just don't get it, but that's not a surprise. I'm booting a 2.6.23
kernel on an MPC8347 using u-boot 1.3.0. I'm trying to use the device
tree to spec my single Spansion/AMD NOR flash part and I can't get the
kernel to recognize the part. Or maybe I just don't know how to tell if
the kernel is recognizing the part. It's possible that everything is fine
and I'm just to dumb to know it.
So I've got a Spansion S29GL128N flash part and the following entry in my
device tree:
[EMAIL PROTECTED] {
What bus is this node under in your DTS file? Make sure that bus is
getting probed in the platform code.
josh
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Problem compiling sequoia using DENX kernel. Xenomai-patch required?
On Tue, 4 Dec 2007 23:14:38 +0100 Niklaus Giger [EMAIL PROTECTED] wrote: Am Dienstag, 4. Dezember 2007 schrieb Wolfgang Denk: ... I'm afraid normal here still means arch/ppc - hopefully for not long any more. Note: a matching Xenomai patch for arch/ppc will be in Xenomai 2.4 when it comes out in a few days. Thanks a lot for your explanation. I took ksrc/arch/powerpc/patches/adeos-ipipe-2.6.23-ppc-1.6-00.patch from the xenomai trunk and was able to compile and boot successfully the yosemite board (using ARCH=ppc). Will try the sequoaia board tomorrow. I hope that this is a good starting point to get my custom PPC440EPx board into shape. I think once the arch/powerpc will work for PPC440 it should not be a lot of work to port it from ppc - powerpc. Sequoia is already in arch/powerpc. At least most of the base support. josh ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Unable to Read PPC440EPx Board ID thru Board Control and Status Registers (BCSR)
On Tue, 27 Nov 2007 02:47:45 -0800 (PST)
Dell Query [EMAIL PROTECTED] wrote:
Hi,
I am creating a simple program which will try to read the board ID of the
PPC440EPx thru BCSR but when I load it, it gives me Data Read PLB Error.
I am not sure if I missed out something.
I would really appreciate it if somebody could help me on this.
I have posted the source code below, as well as the complete message.
Many thanks!
SOURCE CODE:
--
#include linux/module.h
#include linux/kernel.h
#include linux/ioport.h
#include linux/delay.h
#include linux/init.h
#include linux/interrupt.h
#include linux/platform_device.h
#include asm/irq.h
#include asm/io.h
#include linux/i2c.h
#include linux/i2c-id.h
#include asm/ocp.h
#include asm/ibm4xx.h
MODULE_LICENSE(GPL);
#define BCSR_BASE 0xC0002000
This is wrong. It's 0x1C0002000.
#define BCSR0 0
#define BCSR1 1
#define BCSR2 2
#define USER_LED0x2
#define SIZE_TO_MAP 10
#define LED_ON 0
uint __iomem *bcsrbase = NULL;
static int __init initFunction(void) {
uint tmp;
printk(1 Calling init function.\n);
printk(1 bcsrbase value %p...\n,bcsrbase);
printk(1 Remapping %x...\n,BCSR_BASE);
/*map*/
bcsrbase = ioremap(BCSR_BASE, SIZE_TO_MAP);
Since this seems to be arch/ppc, use ioremap64.
josh
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH/RFC] powerpc: Pass PID argument to _tlbie (WAS: Apparent kernel bug with GDB on ppc405)
On Sat, 27 Oct 2007 17:32:02 +1000 Benjamin Herrenschmidt [EMAIL PROTECTED] wrote: Allright, so Matt, let me know if that fixes your problem with gdb, and I'll clean the patch up a bit and submit it. I want to double check if something similar may be needed for freescale booke. Basically, the problem is that things like get_user_pages() can cause COW operations which in turn call _tlbie() to be called for translations that aren't in the current address space. The current 40x and 44x implementation of _tlbie doesn't handle that properly as it only invalidates entries in the current PID. This is an attempt at fixing it. Untested, I just checked it builds for arch/powerpc and arch/ppc. I also haven't looked whether the freescale BookE _tlbie needs similar treatement (it will get passed the pid in r4 with that patch, so if it needs to do something with it, it can). Kumar, can you have a look ? This looks pretty good at first glance. I'll try to test it out today, but I'd still like to hear if it solves Matt's problem as I doubt I'll be able to duplicate it. josh ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH/RFC] powerpc: Pass PID argument to _tlbie (WAS: Apparent kernel bug with GDB on ppc405)
On Mon, 29 Oct 2007 07:08:24 -0500 Josh Boyer [EMAIL PROTECTED] wrote: On Sat, 27 Oct 2007 17:32:02 +1000 Benjamin Herrenschmidt [EMAIL PROTECTED] wrote: Allright, so Matt, let me know if that fixes your problem with gdb, and I'll clean the patch up a bit and submit it. I want to double check if something similar may be needed for freescale booke. Basically, the problem is that things like get_user_pages() can cause COW operations which in turn call _tlbie() to be called for translations that aren't in the current address space. The current 40x and 44x implementation of _tlbie doesn't handle that properly as it only invalidates entries in the current PID. This is an attempt at fixing it. Untested, I just checked it builds for arch/powerpc and arch/ppc. I also haven't looked whether the freescale BookE _tlbie needs similar treatement (it will get passed the pid in r4 with that patch, so if it needs to do something with it, it can). Kumar, can you have a look ? This looks pretty good at first glance. I'll try to test it out today, but I'd still like to hear if it solves Matt's problem as I doubt I'll be able to duplicate it. Did a boot test on my ebony board with this patch included. It seems to be happy about things so far. If Matt gets around to trying this out and it works, we should probably look at getting this into 2.6.24. Oh, and I'd need a signed-off-by for it Ben :) josh ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Apparent kernel bug with GDB on ppc405
On Fri, 26 Oct 2007 11:51:22 +1000 Benjamin Herrenschmidt [EMAIL PROTECTED] wrote: On Wed, 2007-10-24 at 18:41 -0400, Daniel Jacobowitz wrote: On Wed, Oct 24, 2007 at 05:32:50PM -0500, Matt Mackall wrote: Not completely implausible, but a) why isn't this seen on basically every machine with software TLB? b) why does -local- GDB, which is presumably doing much less work than gdbserver + network stack, not fail? You said it yourself. Local gdb does more work - blows through more TLB entries. I can't answer you about the other half, but I'm pretty sure TLB invalidation is already supposed to be happening... somewhere. Yes. do_wp_page() - ptep_clear_flush() - flush_tlb_page() Aren't there cases in do_wp_page that don't call ptep_clear_flush? Seems anonymous pages, and possibly shared writeable pages skip that step if reuse is true. josh ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Apparent kernel bug with GDB on ppc405
On Sat, 2007-10-27 at 11:36 +1000, Benjamin Herrenschmidt wrote: On Fri, 2007-10-26 at 15:41 -0500, Josh Boyer wrote: On Fri, 26 Oct 2007 11:51:22 +1000 Benjamin Herrenschmidt [EMAIL PROTECTED] wrote: On Wed, 2007-10-24 at 18:41 -0400, Daniel Jacobowitz wrote: On Wed, Oct 24, 2007 at 05:32:50PM -0500, Matt Mackall wrote: Not completely implausible, but a) why isn't this seen on basically every machine with software TLB? b) why does -local- GDB, which is presumably doing much less work than gdbserver + network stack, not fail? You said it yourself. Local gdb does more work - blows through more TLB entries. I can't answer you about the other half, but I'm pretty sure TLB invalidation is already supposed to be happening... somewhere. Yes. do_wp_page() - ptep_clear_flush() - flush_tlb_page() Aren't there cases in do_wp_page that don't call ptep_clear_flush? Seems anonymous pages, and possibly shared writeable pages skip that step if reuse is true. Nah, if that was broken, everybody would be in bad shape. I think I know what's up, see my other email. Yeah, I figured that out after I sent this anyway. In those cases it should likely get flushed from ptep_set_access_flags. josh ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Ocotea board?
On Wed, 24 Oct 2007 06:36:11 +1000 Benjamin Herrenschmidt [EMAIL PROTECTED] wrote: On Tue, 2007-10-23 at 11:13 -0700, Jeff Mock wrote: Is the Ocotea board (the original 440GX eval board) still interesting? I'm wrapping up a project using the 440GX, I started out hacking on the Ocotea board to get started, but we moved off Ocotea long ago onto our own hardware. I'm cleaning up the lab now that the project is nearly finished and I would like to give the board to someone that will put it to good use. I've sponged off this mailing list quite a lot, it's about time I give a little something back. Well, the ocotea has an interesting feature related to the way the ethernet PHY an EMAC interact which I haven't dealt with in the new EMAC driver at this stage. I -think- the Taishan I have may have the same issue though, in which case I won't need it, but if not, I could have good use (or Josh in Rochester) for one of these. Hardware is always welcome. I actually care about 4xx so if Ben doesn't want it then I'm sure I could find a good home... josh ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: PPC440EPx GPIO control help
On Tue, 2007-10-16 at 23:21 -0700, Jeff Mock wrote: David Hawkins wrote: I have a PPC440EPx Sequoia Evaluation board that runs on Linux 2.6.21. What I would want to do is to control (write and read values to) its GPIO. Perhaps similar to Turbo C's outputb(0x378,0x01) to write and inportb(0x378) to read. I read the PPC440EPx manual but I find it difficult to understand. Could anyone show me any tutorial or some sample codes? I copied the code below from some test code I wrote for a TS7300 board (uses an ARM EP9302 processor). However, since its user-space code it should work fine. I might be a little out of date, but I think you must write your own driver to wiggle the GPIO pins on a 440 processor. I just finished a project using a 440GX with a 2.6.15 kernel (we froze the code about 8 months ago). The 440 powerPC core is a 32-bit processor with 36-bit physical addresses. The physical address for the GPIO pins is someplace above 4GB. An mmap() of /dev/mem only lets you map the lower 4GB of the address space, as a result you can't write a user space program on the 440 to wiggle the GPIO pins. (This was true with 2.6.15, I can't speak for later kernels). This depends on the 440 chip itself. If I recall correctly, the 440EP(x) chips don't have I/O above 4GB. josh ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: loading NOR flash from DT
On Wed, 17 Oct 2007 21:26:51 +0200 Sebastian Siewior [EMAIL PROTECTED] wrote: Hello, I have here a MPC8544 DS board with NOR flash on it and Kumar's git tree. I'm trying to detect this flash with the physmap_of module. I added a nor_flash block (I used sequoia.dts as an example) into my device tree on the same level as soc8544 or memory (or between them). After modprobing physmap_of nothing happend. Then I tried to make a tree with plb - opb - ebc and finally nor_flash but still nothing changed. Is there a user space dependency or did I just edit my device tree the wrong way? Any hints are welcome :) Post your device tree please. I don't recall MPC8544 even having PLB, OPB, or EBC busses, so they likely aren't getting probed. josh ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: PPC440EPx GPIO control help
On Wed, 17 Oct 2007 13:26:42 -0700 Jeff Mock [EMAIL PROTECTED] wrote: Josh Boyer wrote: On Tue, 2007-10-16 at 23:21 -0700, Jeff Mock wrote: David Hawkins wrote: I have a PPC440EPx Sequoia Evaluation board that runs on Linux 2.6.21. What I would want to do is to control (write and read values to) its GPIO. Perhaps similar to Turbo C's outputb(0x378,0x01) to write and inportb(0x378) to read. I read the PPC440EPx manual but I find it difficult to understand. Could anyone show me any tutorial or some sample codes? I copied the code below from some test code I wrote for a TS7300 board (uses an ARM EP9302 processor). However, since its user-space code it should work fine. I might be a little out of date, but I think you must write your own driver to wiggle the GPIO pins on a 440 processor. I just finished a project using a 440GX with a 2.6.15 kernel (we froze the code about 8 months ago). The 440 powerPC core is a 32-bit processor with 36-bit physical addresses. The physical address for the GPIO pins is someplace above 4GB. An mmap() of /dev/mem only lets you map the lower 4GB of the address space, as a result you can't write a user space program on the 440 to wiggle the GPIO pins. (This was true with 2.6.15, I can't speak for later kernels). This depends on the 440 chip itself. If I recall correctly, the 440EP(x) chips don't have I/O above 4GB. At first I thought you were right, I remember something about the 440GX being the weird processor with I/O mapped above 4GB. I just took a look at the 440EPx datasheet on the AMCC website and it looks like the GPIO registers are mapped above 4GB: GPIO0 controller 1 EF60 0B00 GPIO1 controller 1 EF60 0C00 Actually, it's 440EP that has the addresses below 4GB, not 440EPx. My apologies for the confusion. As far as weird goes in the 44x world, 440EP is the oddball as I believe most all other 44x versions have some if not all I/O above 4GB. josh ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH] Add platform support for the MPC837x RDB board
On Mon, 01 Oct 2007 15:49:22 -0400 Ben Warren [EMAIL PROTECTED] wrote: Mark A. Greer wrote: On Thu, Sep 27, 2007 at 04:28:30PM -0500, Olof Johansson wrote: On Thu, Sep 27, 2007 at 03:03:12PM -0500, Josh Boyer wrote: On Thu, 27 Sep 2007 12:53:51 -0700 Mark A. Greer [EMAIL PROTECTED] wrote: On Thu, Sep 27, 2007 at 12:41:57PM -0700, D'Abbraccio Joe-ljd015 wrote: Thanks for the advice, but I was just basing the list to post to on the MAINTAINERS file which states that this is the one for Embedded PPC83XX. If you still think that I should post to linuxppc-dev, let me know. Yes, I think it would be better to repost to linuxppc-dev. Does anyone have an objection to changing all of the: L: linuxppc-embedded@ozlabs.org in MAINTAINERS to: L: [EMAIL PROTECTED] ?? Kumar, Josh, Vitaly, et. al.? I personally don't care either way. I'm already subscribed to both lists. Makes sense to go to linuxppc-dev given the arch/powerpc migration. I thought the -embedded list was created in the first place to keep some of the noise off of -dev (i.e. I can't get interface foo to work on my custom embedded eval board-lookalike board, HELP!). If people still care about keeping that on a separate list, then we shouldn't change it. Yes, IIRC, that was the reason but now with the merge and low volume on this list, it makes sense to me to just get rid of -embedded. Perhaps my perspective is unique, but I doubt it. I find it nice that this list is low volume and not filled with endless patches about CHRP and P series and open firmware syntax blah blah blah... No offense intended to all the people who are doing wonderful work expanding the Linux universe, but for your average dude or dudette working on embedded boards that happen to have a PowerPC processor, this list is a pretty good forum. I think the original thought was to have patches go to linuxppc-dev. Not necessarily all discussion. josh ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH] Add platform support for the MPC837x RDB board
On Thu, 27 Sep 2007 12:53:51 -0700 Mark A. Greer [EMAIL PROTECTED] wrote: On Thu, Sep 27, 2007 at 12:41:57PM -0700, D'Abbraccio Joe-ljd015 wrote: Thanks for the advice, but I was just basing the list to post to on the MAINTAINERS file which states that this is the one for Embedded PPC83XX. If you still think that I should post to linuxppc-dev, let me know. Yes, I think it would be better to repost to linuxppc-dev. Does anyone have an objection to changing all of the: L: linuxppc-embedded@ozlabs.org in MAINTAINERS to: L: [EMAIL PROTECTED] ?? Kumar, Josh, Vitaly, et. al.? I personally don't care either way. I'm already subscribed to both lists. Makes sense to go to linuxppc-dev given the arch/powerpc migration. josh ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: EBC peripheral, access causing Machine Check
On Mon, 24 Sep 2007 12:19:01 -0700 Dave Cogley [EMAIL PROTECTED] wrote: Good Afternoon, I am using an AMCC 440EPx processor with an FPGA peripheral attached to the EBC. I am doing the entire bank configuration in the u-boot boot loader before Linux is loaded. I can directly read and write registers using memory read and write (md, nm) within area 0xC000 to 0xC000 direct memory I/O within the context of u-boot without any faults. When I attempt to access any register in area 0xC00 within the context of my Linux device driver I get a Machine Check fault (attached text) which appears to be an access permission violation. I am currently running the DENX ELDK 2.6.19.2 platform that was specific to the Sequoia platform. I have configured the EBC access permissions and control resisters as follows for bank 1: PB1CR: 0xC003C000 PB1AP: 0x80040380 You need proper TLB entries set up before you can access things. Linux discards the MMU settings that U-Boot does. So your driver needs to call ioremap on the physical address. Other than that, we can't help you much without your driver code. josh ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Printing device tree on running system
On Thu, 2007-09-20 at 12:21 -0400, Jon Smirl wrote: On 9/20/07, Scott Wood [EMAIL PROTECTED] wrote: On Thu, Sep 20, 2007 at 11:55:10AM -0400, Jon Smirl wrote: Is there a command for printing the device tree on a running system? I want to see what changes the various device drivers made to the DTC I started with. It's exported in /proc/device-tree, if support is built into the kernel. That worked, didn't know the option existed. It might be interesting to make dtc support turning that into a dts... dtc does support that. Pass /proc/device-tree/ to dtc like this: dtc -I fs -o device-tree.dts -O dts /proc/device-tree josh ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Device tree compiler
On Mon, 17 Sep 2007 13:30:37 +0200 Laurent Pinchart [EMAIL PROTECTED] wrote: Hi everybody, I'm trying to port a MPC8248-based board from ppc to powerpc. While looking for example DTS files I found out that the Linux kernel sources include a few of them in arch/powerpc/boot/dts. However, they don't compile with the latest device-tree compiler available at git://ozlabs.org/srv/projects/dtc/dtc.git. Because that is ancient. Use the one from: git://www.jdl.com/software/dtc.git Someone should really fix up the ozlabs page to stop pointing at outdated versions of DTC. josh ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Support a new platform in arch/ppc or in arch/powerpc ?
On Thu, 6 Sep 2007 18:53:54 +0200 CHAVENT Paul [EMAIL PROTECTED] wrote: Good morning. I would like to port a bsp (for the motorola MVME5500 sbc) to the current (2.6.22.6) kernel. Should i implement it in arch/powerpc ? Yes. arch/ppc is bug fix only at this point. If i should do it in arch/powerpc, can i copy some code i need in arch/ppc ? For example, with kernel 2.6.18.1 i used arch/ppc/syslib/todc_time and arch/ppc/syslib/pci_auto, but perhaps i don't need it anymore ? I'm not sure those will work well in arch/powerpc. But obviously some code porting is expected. josh ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: finding out the processor frequency
On Thu, 6 Sep 2007 13:43:08 -0500 Scott Wood [EMAIL PROTECTED] wrote: On Thu, Sep 06, 2007 at 02:24:30PM -0400, Leisner, Martin wrote: What exactly do we mean by timebase? There a symbol in arch/powerpc/time.c:ppc_proc_freq which looks like the processor frequency (derived from the dts). But its not exported. There's also ppc_tb_freq. The timebase is the rate at which the timebase and decrementer registers tick. It is not the same as the CPU core frequency. Unless your timebase and decrementer clock source is tied to the CPU clock. :) So it depends on the board, and it can even depend on how the board is initialized. Some boards can change the timebase clock source on the fly. josh ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: disable interrput under ppc?
On Tue, 4 Sep 2007 13:24:33 -0500 Scott Wood [EMAIL PROTECTED] wrote: On Tue, Sep 04, 2007 at 10:44:14AM +0800, Wang, Baojun wrote: hi, list How can I disable interrput like `cli' in x86? local_irq_disable(). I want the following code freeze the box but it doesn't, $MSR is altered however the box is still alive, how can I freeze the box like `cli' in x86? Thanks very much! Disabling interrupts doesn't freeze the machine by itself -- it depends on what you do afterwards, which you didn't show. If you're using a BOOKE variant, there is a way to use the DBCR0 register to set debug wait enable or something to basically hang the CPU until something external clears that bit. But why you would want to do that, I have no idea. josh ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: spin_lock doesn't work?!?
On Wed, 29 Aug 2007 23:30:22 -0700 (PDT) melinda develey [EMAIL PROTECTED] wrote: You should still put the spin_lock calls into your code because you never know if someone else will compile it and for another target. If someone would, for example, compile the same code for a SMP machine then the spin_lock will actually lock. I used the spinlock both in an interrupt handler to protect a group of variables (because in an interrupt I can't use a semaphore) and the same spinlock in a ioctl handler where the same group of variables is accessed. Is this wrong? I have a 2.6.19.2 linux kernel. You might want to use spin_lock_irq instead. That will disable interrupts in the critical section in the ioctl. Seems more like what you are trying to do. josh ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Xilinx Virtex4 FX PPC
On Tue, 21 Aug 2007 11:52:35 +0300 Stelios Koroneos [EMAIL PROTECTED] wrote: Question 1: Do I need a special glibc for the Xilinx PPC 405 FYI we are at the last stage of implementing OpenEmbedded support for the Xilinx ml403 (and hopefully other Xilinx boards in the near future) Cool. It also handles the EDK header copying procedure automagically i.e you point to your EDK project dir and pulls the file(s) it needs for the kernel. We will be working to automate the generation of ACE files also, since OE generates a full image (kernel+fs) and not just the toolchain. Currently toolchain is gcc 4.1.1 with glibc 2.5 and/or uclibc 0.9.28. There is some work done by other OE developers to get eglibc going (omap works according to the latest info i have) OpenEmbedded supports a number of ppc targets currently walnut (405),sequoia(440e),efika(603e) just to mention a few I will be speaking at the Power.org dev conference about OE and power architecure so if anyone will be there and wishes to get some knowledge about OE in advance , feel free to drop me a mail, as we will releasing a beta of our OE based distro soon. I'm hoping to attend as well. Should be interesting. josh ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH 3/3] Add support for xupv2p and ml410 boards.
On Tue, 21 Aug 2007 17:53:13 -0700
[EMAIL PROTECTED] wrote:
From: Stephen Neuendorffer [EMAIL PROTECTED]
xupv2p support generates MAC addresses based on a silicon serial ID.
General reminder, no new code will be accepted in arch/ppc. It's in
bugfix state only.
I of course have no problems with people sending patches for new stuff,
but I don't want people to get the idea that it will wind up in tree.
+#include linux/xilinx_devices.h
+#include platforms/4xx/xparameters/xparameters.h
+
+int virtex_device_fixup(struct platform_device *dev)
Could this be a static function?
+{
+#ifdef XPAR_ONEWIRE_0_BASEADDR
+ int i;
+ // Use the Silicon Serial ID attached on the onewire bus to
+ // generate sensible MAC addresses.
No C++ style comments please.
+ unsigned char *p_onewire = ioremap(XPAR_ONEWIRE_0_BASEADDR, 6);
What happens if ioremap fails?
+ struct xemac_platform_data *pdata = dev-dev.platform_data;
+ if (strcmp(dev-name, xilinx_emac) == 0) {
+ printk(KERN_INFO Fixup MAC address for %s:%d\n,
+dev-name, dev-id);
+ // FIXME.. this doesn't seem to return data that is consistent
+ // with the self test... why not?
+ pdata-mac_addr[0] = 0x00;
+ pdata-mac_addr[1] = 0x0A;
+ pdata-mac_addr[2] = 0x35;
+ pdata-mac_addr[3] = dev-id;
+ pdata-mac_addr[4] = p_onewire[4];
+ pdata-mac_addr[5] = p_onewire[5];
+ pr_debug(KERN_INFO
+ MAC address is now %2x:%2x:%2x:%2x:%2x:%2x\n,
+ pdata-mac_addr[0], pdata-mac_addr[1],
+ pdata-mac_addr[2], pdata-mac_addr[3],
+ pdata-mac_addr[4], pdata-mac_addr[5]);
+ }
+ iounmap(p_onewire);
+#endif
+ return 0;
+}
--- /dev/null
+++ b/arch/ppc/platforms/4xx/xparameters/xparameters_ml41x.h
@@ -0,0 +1,277 @@
+
+/***
+*
+* CAUTION: This file is automatically generated by libgen.
+* Version: Xilinx EDK 8.2.02 EDK_Im_Sp2.4
+* DO NOT EDIT.
+*
+* Copyright (c) 2005 Xilinx, Inc. All rights reserved.
All rights reserved is not compatible with the GPL I don't think...
josh
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Xilinx Virtex4 FX PPC
On Mon, 20 Aug 2007 10:00:54 -0600 Robert Woodworth [EMAIL PROTECTED] wrote: Problem 2: Build my own rootfs. If I try to build my own programs (busybox and bash at this point) with shared libc using the same glibc from my toolchain, I get an Illegal instruction error. Is my glibc not compatible with my Xilinx PPC 405?? If I try to build a rootfs with debian ppc packages I have the same Illegal instruction error. Question 1: Do I need a special glibc for the Xilinx PPC 405 Does a normal PPC glibc have more advanced instructions compiled in that will not work on a Xilinx PPC 405?? Make sure you're building glibc with soft-fp, or make sure you have CONFIG_MATH_EMULATION enabled in your kernel. The PPC 405 doesn't have an FPU. josh ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH] [292/2many] MAINTAINERS - LINUX FOR POWERPC EMBEDDED PPC4XX
On Sun, 12 Aug 2007 23:31:11 -0700 [EMAIL PROTECTED] wrote: Add file pattern to MAINTAINER entry Signed-off-by: Joe Perches [EMAIL PROTECTED] diff --git a/MAINTAINERS b/MAINTAINERS index 0862965..38810b7 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -2804,6 +2804,8 @@ M: [EMAIL PROTECTED] W: http://www.penguinppc.org/ L: linuxppc-embedded@ozlabs.org S: Maintained +F: arch/ppc/syslib/ppc4xx_* +F: include/asm-ppc/ppc4xx_* You're missing arch/ppc/platforms/4xx/, among other things. Also, we're in the middle of merging 4xx to arch/powerpc. josh ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH] [292/2many] MAINTAINERS - LINUX FOR POWERPC EMBEDDED PPC4XX
On Mon, 13 Aug 2007 10:35:01 -0700 Joe Perches [EMAIL PROTECTED] wrote: On Mon, 2007-08-13 at 06:18 -0500, Josh Boyer wrote: You're missing arch/ppc/platforms/4xx/, among other things. Also, we're in the middle of merging 4xx to arch/powerpc. We can leave the whole block unmodified until you're ready. LINUX FOR POWERPC EMBEDDED PPC4XX P:Matt Porter M:[EMAIL PROTECTED] W:http://www.penguinppc.org/ L:linuxppc-embedded@ozlabs.org S:Maintained Yeah. I would actually prefer that, thanks. josh ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Fedora 7 on a non FPU system
On Tue, 07 Aug 2007 12:42:41 -0500 Michael Brian Willis [EMAIL PROTECTED] wrote: Hello, I'm trying to install a Fedora 7 Root File System on an MPC8540 based embedded system with a Denx 2.6.21 kernel. I have read the Denx Application note located at: http://www.denx.de/wiki/DULG/AN2007_03_InstallFC7OnSequoia. However this App. Note says that the instructions apply only to processors that have a full Floating Point Unit (FPU). My processor does not have an FPU and I believe that this is causing some system hangs. Has anybody every successfully installed Fedora(or another major distro) on a non-FPU system? Or, does anybody know what is needed to get it working properly on a non FPU system? CONFIG_MATH_EMULATION in the kernel will emulate floating point instructions. Try that. josh ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
