* [PATCH 2.6.10-rc2] ppc32: Add usb support to IBM stb04xxx platforms including Redwood5
From: Dale Farnsworth @ 2005-03-31 0:05 UTC (permalink / raw)
To: linuxppc-embedded
Signed-off-by: Dale Farnsworth <dale@farnsworth.org>
Index: linux-2.5-usb-405/arch/ppc/platforms/4xx/ibmstb4.c
===================================================================
--- linux-2.5-usb-405.orig/arch/ppc/platforms/4xx/ibmstb4.c
+++ linux-2.5-usb-405/arch/ppc/platforms/4xx/ibmstb4.c
@@ -11,6 +11,7 @@
#include <linux/init.h>
#include <asm/ocp.h>
+#include <asm/usb.h>
#include <platforms/4xx/ibmstb4.h>
static struct ocp_func_iic_data ibmstb4_iic0_def = {
@@ -72,12 +73,70 @@
.irq = IDE0_IRQ,
.pm = OCP_CPM_NA,
},
- { .vendor = OCP_VENDOR_IBM,
- .function = OCP_FUNC_USB,
- .paddr = USB0_BASE,
- .irq = USB0_IRQ,
- .pm = OCP_CPM_NA,
- },
{ .vendor = OCP_VENDOR_INVALID,
}
};
+
+/* Power up the USB subsection */
+static int enable_usb(struct platform_device *pdev)
+{
+ u32 mask;
+
+ mask = 1 << (31 - USB0_IRQ);
+ mtdcr(DCRN_UIC_PR(UIC0), mfdcr(DCRN_UIC_PR(UIC0)) | mask);
+ mtdcr(DCRN_UIC_TR(UIC0), mfdcr(DCRN_UIC_TR(UIC0)) & ~mask);
+ return 0;
+}
+
+/* Power down the USB subsection */
+static void disable_usb(struct platform_device *pdev)
+{
+ u32 mask;
+
+ mask = 1 << (31 - USB0_IRQ);
+ mtdcr(DCRN_UIC_PR(UIC0), mfdcr(DCRN_UIC_PR(UIC0)) & ~mask);
+ mtdcr(DCRN_UIC_TR(UIC0), mfdcr(DCRN_UIC_TR(UIC0)) | mask);
+}
+
+static struct usb_hcd_platform_data pd = {
+ .start = enable_usb,
+ .stop = disable_usb,
+};
+
+static struct resource ohci_usb_resources[] = {
+ [0] = {
+ .start = USB0_BASE,
+ .end = USB0_BASE + USB0_SIZE - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ [1] = {
+ .start = USB0_IRQ,
+ .end = USB0_IRQ,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static u64 dma_mask = 0xffffffffULL;
+
+static struct platform_device ohci_usb_device = {
+ .name = "ppc-soc-ohci",
+ .id = 0,
+ .num_resources = ARRAY_SIZE(ohci_usb_resources),
+ .resource = ohci_usb_resources,
+ .dev = {
+ .dma_mask = &dma_mask,
+ .coherent_dma_mask = 0xffffffffULL,
+ .platform_data = &pd,
+ }
+};
+
+static struct platform_device *ibmstb4_devs[] __initdata = {
+ &ohci_usb_device,
+};
+
+static int __init
+ibmstb4_platform_add_devices(void)
+{
+ return platform_add_devices(ibmstb4_devs, ARRAY_SIZE(ibmstb4_devs));
+}
+arch_initcall(ibmstb4_platform_add_devices);
Index: linux-2.5-usb-405/arch/ppc/platforms/4xx/ibmstb4.h
===================================================================
--- linux-2.5-usb-405.orig/arch/ppc/platforms/4xx/ibmstb4.h
+++ linux-2.5-usb-405/arch/ppc/platforms/4xx/ibmstb4.h
@@ -73,9 +73,9 @@
#define OPB0_BASE 0x40000000
#define GPIO0_BASE 0x40060000
+#define USB0_BASE 0x40010000
+#define USB0_SIZE 0xA0
#define USB0_IRQ 18
-#define USB0_BASE STB04xxx_MAP_IO_ADDR(0x40010000)
-#define USB0_EXTENT 4096
#define IIC_NUMS 2
#define UART_NUMS 3
Index: linux-2.5-usb-405/include/asm-ppc/usb.h
===================================================================
--- /dev/null
+++ linux-2.5-usb-405/include/asm-ppc/usb.h
@@ -0,0 +1,14 @@
+/*
+ * ppc/usb.h:
+ *
+ */
+#ifndef _PPC_USB_H
+#define _PPC_USB_H
+
+struct usb_hcd_platform_data {
+ char *name;
+ int (*start) (struct platform_device *pdev);
+ void (*stop) (struct platform_device *pdev);
+};
+
+#endif /* !(_PPC_USB_H) */
^ permalink raw reply
* Re: [PATCH] sleep & cpufreq problems
From: Benjamin Herrenschmidt @ 2005-03-30 22:32 UTC (permalink / raw)
To: linuxppc-dev list; +Cc: debian-powerpc@lists.debian.org
In-Reply-To: <1112066934.6809.4.camel@gaston>
On Tue, 2005-03-29 at 13:28 +1000, Benjamin Herrenschmidt wrote:
> Hi !
>
> Here are a couple of patches against current linus bk (one was already
> posted to this list) that should fix a number issues related to sleep
> and wakeup, especially in conjunction with cpufreq transitions.
>
> Please test and let me know if it fixes a problem you had, it adds a new
> problem, or it has no effect, stuff still doesn't work (if it used to
> work and still work, no need to bug me).
>
> Thanks !
>
> Patches are at:
>
> http://gate.crashing.org/~benh/ppc32-pmac-sleep-fix.diff
> http://gate.crashing.org/~benh/ppc32-cpufreq-gpio-off.diff
Ok, I re-updated them, if you have sleep, cpufreq or both problems, try
and let me know.
THe first one should apply on 2.6.11, the second one applies only on top
of current bk.
Ben.
^ permalink raw reply
* Re: USB support on Lite5200
From: Wolfgang Denk @ 2005-03-30 21:40 UTC (permalink / raw)
To: Edward Jubenville; +Cc: linuxppc-embedded
In-Reply-To: <GPECLCIGPLHEOMGPMCPAOEOJCMAA.edjubenville@adelphia.net>
Dear Ed,
in message <GPECLCIGPLHEOMGPMCPAOEOJCMAA.edjubenville@adelphia.net> you wrote:
> I'm using a FreeScale Lite5200 development board with an MPC5200. I used
> ELDK 1.3 and DAS U-Boot to get a working kernel, booted, etc., but I later
> found that the configuration I chose (icecube_5200_defconfig) didn't have
> USB support enabled.
>
> My first USB goal is hook up a SanDisk cruzer 256 MB memory stick. Which
> configuration options need to change? Is there a HOWTO or example
> configuration file somewhere?
See Documentation/Configure.help for a description of the configu-
ration options.
> Eventually, I would like to support at least one kind of USB keyboard.
> Where can I find guidance for that configuration.
For a start, you can use the "icecube_5200_CoralP" which has USB
support (for mouse, keyboard, mass storage devices) enabled.
For example, compare the config files like this:
diff arch/ppc/configs/icecube_5200{,_CoralP}_defconfig
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Brontosaurus Principle: Organizations can grow faster than their
brains can manage them in relation to their environment and to their
own physiology: when this occurs, they are an endangered species.
- Thomas K. Connellan
^ permalink raw reply
* USB support on Lite5200
From: Edward Jubenville @ 2005-03-30 20:57 UTC (permalink / raw)
To: linuxppc-embedded
I'm using a FreeScale Lite5200 development board with an MPC5200. I used
ELDK 1.3 and DAS U-Boot to get a working kernel, booted, etc., but I later
found that the configuration I chose (icecube_5200_defconfig) didn't have
USB support enabled.
My first USB goal is hook up a SanDisk cruzer 256 MB memory stick. Which
configuration options need to change? Is there a HOWTO or example
configuration file somewhere?
Eventually, I would like to support at least one kind of USB keyboard.
Where can I find guidance for that configuration.
If there's a better place to post these questions, please advise.
Thanks in advance,
Ed
^ permalink raw reply
* Re: ptrace and ORIG_EAX on ppc
From: ashwin tanugula @ 2005-03-30 19:15 UTC (permalink / raw)
To: Brad Boyer; +Cc: linuxppc-dev
In-Reply-To: <20050330072558.GA13087@pants.nu>
On Tue, 29 Mar 2005 23:25:58 -0800, Brad Boyer <flar@allandria.com> wrote:
> On Tue, Mar 29, 2005 at 08:01:06PM -0500, ashwin tanugula wrote:
> > Hi!
> > Can somebody tell me how to set references to ORIG_EAX in ppc kernel.
> > We know ORIG_EAX is defined in unistd.h of i386. How do i make the
> > following program print two same pids in ppc?
>
> The ORIG_EAX is a reference to a register as saved in the stack. The
> equivalent on ppc would seem to be PT_ORIG_R3. You're digging around
> in an area that is extremely non-portable. This program appears to
> be messing around with the syscall number before dispatch in the
> syscall table. The implementation of ptrace on ppc and ppc64
> explicitly does not allow changing this value, so I think you'll need
> to find a completely different way to achieve your desired result.
>
> Just to lessen the confusion, what are you trying to accomplish? Not
> in the low-level detail sense, but what is the big picture goal?
>
> Brad Boyer
> flar@allandria.com
>
>
Hi,
Thanks to Brad for his help.
ORIG_EAX has to be changed to PT_R0 not to PT_ORIG_R3.
The output i got after changing ORIG_EAX to PT_R0 is
root@slemieux:/home/ashwin # gcc ptrace_test.c
root@slemieux:/home/ashwin # ./a.out
Parent pid = 16682
getpid() returned 16682
getpid() returned 16682
--Ashwin.
^ permalink raw reply
* 36-bit phys & 64-bit pte support
From: Kumar Gala @ 2005-03-30 17:58 UTC (permalink / raw)
To: Matt Porter; +Cc: Linux PPC Embedded list
Matt,
It looks like you introduced two config options at one point, however
they dont seem to be used consitently today. I wanted to clarify the
meaning that I'm going to try and go forward with:
CONFIG_PTE_64BIT - we have a 64-bit PTE
CONFIG_PHYS_64BIT - we have larger than 32-bit physical addresses
Its feasible to have support for CONFIG_PTE_64BIT while only supporting
32-bit phys. The intent would be if you needed more flags than you
could handle in the 12 LSBs of the pte.
CONFIG_PHYS_64BIT will only effect things like ioremap, phys_addr_t,
etc.
Do you agree with this interpretation?
- kumar
^ permalink raw reply
* Re: Problem running Linux 2.6.11 on MPC8272ADS
From: Kumar Gala @ 2005-03-30 17:42 UTC (permalink / raw)
To: Walter L. Wimer III; +Cc: Linux PPC Embedded list
In-Reply-To: <1112198401.24332.8.camel@excalibur.timesys.com>
Also,
If you guys come to some conclusion about a fix we can make to the=20
boards that would improve functionality, I'll try to get that back to=20
the board guys to look at implementing for future revs.
- kumar
On Mar 30, 2005, at 10:00 AM, Walter L. Wimer III wrote:
>
>
> This matched my experience as well.
>
> Does anyone know why U-Boot 1.1.1 from Freescale uses a different BCSR
> address than U-Boot 1.1.1 from Sourceforge?
>
> Any opinions on which address is the "correct" one to use?=A0 Kumar =
asked
> for a patch to fix this, so what do we think the correct fix is?
>
>
>
>
> Thanks!
>
> Walt
>
>
>
>
> On Wed, 2005-03-30 at 10:18 +0200, Mike Rapoport wrote:
> > Walter,
> > Thanks for you help. I've discovered several things and now the=20
> things
> > seem to work fine.
> > I've used u-boot-1.1.1 that came with the Freescale BSP and it maps=20=
> BCSR
> > to 0xf8000000. The "regular" u-boot-1.1.1 (from sf.net) maps the=20
> BCSR to
> > 0xf4500000 as well as the kernel does (arch/ppc/platforms/pq2ads.h).=20=
> The
> > difference causes the "hang"-like behaviour when the kernel=20
> initializes
> > serial comm and kernel crash afterwards when FCC is initialized.
> >
> > Mike.
> >
> > >Thanks for the data points, Alex.
> > >
> > >I'm using U-Boot 1.1.1 and vanilla kernel.org 2.6.11.4 (actually=20=
> now
> > >2.6.11.5).=A0 My BCSR_ADDR looks the same as what you've listed=20
> below, so
> > >I'd guess the difference is with U-Boot...=A0 (Another engineer =
here
> > >installed U-Boot on my board, from, I believe, a binary copy he=20
> got from
> > >a Freescale(?) CD...=A0 I didn't build U-Boot from source...=A0 =
That's
> > >something I'll need to take a look at...)
> > >
> > >Mike, have you discovered anything further about your problem?
> > >
> > >
> > >
> > >Walt
> > >
> > >
> > >
> > >On Tue, 2005-03-29 at 08:29 +0200, Bastos Fernandez Alexandre=20
> wrote:
> > >=A0
> > >
> > >>Hi,
> > >>
> > >>>=46rom "linux/arch/ppc/platforms/pq2ads.h"
> > >>#define BCSR_ADDR ((uint) 0xf4500000)
> > >>>=46rom "u-boot/include/configs/MPC8260ADS.h"
> > >>#define CFG_BCSR 0xF4500000
> > >>So ...
> > >>Which version of u-boot and/or linux tree are you using?
> > >>With linuxppc-2.5 and u-boot 1.2 everything works fine for me.
> > >>Maybe Mike's problem is other. Maybe not. :-)
> > >>
> > >>Best regards,
> > >>Alex
> > >>
> > >>=A0=A0=A0
> > >>
> > >>>-----Original Message-----
> > >>>From:=A0=A0=A0=A0=A0 Walter L. Wimer III =
[SMTP:walt.wimer@timesys.com]
> > >>>Sent:=A0=A0=A0=A0=A0 Monday, March 28, 2005 6:07 PM
> > >>>To:=A0=A0=A0=A0=A0=A0=A0 Mike Rapoport
> > >>>Cc:=A0=A0=A0=A0=A0=A0=A0 linuxppc-embedded@ozlabs.org
> > >>>Subject:=A0=A0 Re: Problem running Linux 2.6.11 on MPC8272ADS
> > >>>
> > >>>
> > >>>Hi Mike,
> > >>>
> > >>>I had the same "hang" experience.=A0 The file=20
> arch/ppc/platforms/pq2ads.c
> > >>>contains the following function:
> > >>>
> > >>>=A0 void __init
> > >>>=A0 m82xx_board_setup(void)
> > >>>=A0 {
> > >>>=A0=A0 /* Enable the 2nd UART port */
> > >>>=A0=A0 *(volatile uint *)(BCSR_ADDR + 4) &=3D ~BCSR1_RS232_EN2;
> > >>>=A0 }
> > >>>
> > >>>
> > >>>I had to ifdef-out the assignment statement above.=A0 It appears=20=
> that the
> > >>>definition for BCSR_ADDR in the kernel code differs from what=20
> U-Boot is
> > >>>using, and that area of memory isn't properly mapped into the=20
> kernel
> > >>>address space this early in the boot sequence.=A0 As a result, I=20=
> was
> > >>>getting an Oops() before the console was even enabled (I could=20=
> see the
> > >>>Oops message by examining the kernel's printk log buffer using a
> > >>>BDI-2000 hardware debugger).
> > >>>
> > >>>
> > >>>
> > >>>Good luck,
> > >>>
> > >>>Walt Wimer
> > >>>TimeSys Corporation
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>On Sun, 2005-03-27 at 11:31 +0200, Mike Rapoport wrote:
> > >>>=A0=A0=A0=A0=A0
> > >>>
> > >>>>Hi,
> > >>>>I'm trying to bring up the Linux 2.6.11 on MPC8272ADS and it=20
> seem to
> > >>>>hang up at the very beginning.
> > >>>>I use ads8272_defconfig and then enable console on SCC:
> > >>>>
> > >>>>CONFIG_SERIAL_CPM=3Dy
> > >>>>CONFIG_SERIAL_CPM_CONSOLE=3Dy
> > >>>>CONFIG_SERIAL_CPM_SCC1=3Dy
> > >>>>
> > >>>>
> > >>>>when I boot the kernel from the u-boot the system hangs up=20
> right after
> > >>>>the kernel decompression.
> > >>>>
> > >>>>=A0=A0=A0=A0=A0=A0=A0
> > >>>>
> > >>>_______________________________________________
> > >>>Linuxppc-embedded mailing list
> > >>>Linuxppc-embedded@ozlabs.org
> > >>>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> > >>>=A0=A0=A0=A0=A0
> > >>>
> > >
> > >
> > >=A0
> > >
> >
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: Platform bus/ppc sys model...
From: Kumar Gala @ 2005-03-30 17:26 UTC (permalink / raw)
To: Jakob Viketoft
Cc: Jon Masters, Sylvain Munaut, Andrei Konovalov,
Linux PPC Embedded list
In-Reply-To: <424ACFF1.5000403@bitsim.se>
> My intention was to give a device tree structure to the kernel at boot
> time via a (pseudo?) pointer in bd_info or similar. Then you would only
> need to recompile a little bootloader (which is needed for setting up
> the FPGA anyway) with this structure for every specific card. You could
> even be shrewd enough to have a single kernel image but several
> structures to launch several processors on the same chip. Does it sound
> like a sane solution?
I think this is reasonable. The best device tree would be a flattened
OF tree since we are trying to move the world in that direction. Jon
Masters around?
> Otherwise, I'm a bit unsure as to whether a system with a gigantic list
> of devices in ???_devices.c is the right way to go. In the Xilinx case,
> not only is a list of possible IP:s needed, but also the usual standard
> circuits which can be connected from outside to the chip. Wouldn't it
> be
> more realistic to have knowledge of the compiled in drivers somehow?
Your needs are a bit different than the initial purpose of ppc_sys.
The reason the device list works well for us today is that it replaced
duplication between every variant of 85xx.
I'm not that familiar with exactly what information you would need to
have access to in the Xilinx case. I would think if you information
compiled into drivers some of this might all be moot. Part of the
whole device model is to have drivers that are agnostic of the system
they are in.
- kumar
^ permalink raw reply
* Re: Platform bus/ppc sys model...
From: Jakob Viketoft @ 2005-03-30 16:12 UTC (permalink / raw)
To: Kumar Gala; +Cc: Andrei Konovalov, Sylvain Munaut, Linux PPC Embedded list
In-Reply-To: <5a325f210dccfd254541824008e8c5a1@freescale.com>
Kumar Gala wrote:
> On Mar 30, 2005, at 7:52 AM, Andrei Konovalov wrote:
>> Do I understand correct that the ppc_sys model used by 85xx, 83xx, and
>> 52xx
>> SOCs is not so well suited for Virtex-II Pro (which Jakob and me bear
>> in mind)?
>> In case of Xilinx ???_devices.c could be the list of all the IPs
>> supported in linux.
>> But ???_sys.c has little sense as for any given combination of the
>> particular
>> Virtex-II Pro chip and the particular board the set of IPs (as well
>> as the memory
>> map, interrupt numbers, some hardware options (if ethernet has SGDMA
>> or not))
>> is not fixed. I.e. ideally we would need some kind of run time system
>> configuration
>> instead of compiled time system configuration implemented by ???_sys.c.
>
>
> This is correct. There is nothing that precludes us from building up a
> way to dynamically create the information. Is there some way to query
> the hardware itself, or is the information implied something else?
>
> - kumar
My intention was to give a device tree structure to the kernel at boot
time via a (pseudo?) pointer in bd_info or similar. Then you would only
need to recompile a little bootloader (which is needed for setting up
the FPGA anyway) with this structure for every specific card. You could
even be shrewd enough to have a single kernel image but several
structures to launch several processors on the same chip. Does it sound
like a sane solution?
Otherwise, I'm a bit unsure as to whether a system with a gigantic list
of devices in ???_devices.c is the right way to go. In the Xilinx case,
not only is a list of possible IP:s needed, but also the usual standard
circuits which can be connected from outside to the chip. Wouldn't it be
more realistic to have knowledge of the compiled in drivers somehow?
/Jakob
^ permalink raw reply
* Re: Problem running Linux 2.6.11 on MPC8272ADS
From: Walter L. Wimer III @ 2005-03-30 16:00 UTC (permalink / raw)
To: Linux PPC Embedded list
In-Reply-To: <424A60E1.4080802@compulab.co.il>
This matched my experience as well.
Does anyone know why U-Boot 1.1.1 from Freescale uses a different BCSR
address than U-Boot 1.1.1 from Sourceforge?
Any opinions on which address is the "correct" one to use? Kumar asked
for a patch to fix this, so what do we think the correct fix is?
Thanks!
Walt
On Wed, 2005-03-30 at 10:18 +0200, Mike Rapoport wrote:
> Walter,
> Thanks for you help. I've discovered several things and now the things
> seem to work fine.
> I've used u-boot-1.1.1 that came with the Freescale BSP and it maps BCSR
> to 0xf8000000. The "regular" u-boot-1.1.1 (from sf.net) maps the BCSR to
> 0xf4500000 as well as the kernel does (arch/ppc/platforms/pq2ads.h). The
> difference causes the "hang"-like behaviour when the kernel initializes
> serial comm and kernel crash afterwards when FCC is initialized.
>
> Mike.
>
> >Thanks for the data points, Alex.
> >
> >I'm using U-Boot 1.1.1 and vanilla kernel.org 2.6.11.4 (actually now
> >2.6.11.5). My BCSR_ADDR looks the same as what you've listed below, so
> >I'd guess the difference is with U-Boot... (Another engineer here
> >installed U-Boot on my board, from, I believe, a binary copy he got from
> >a Freescale(?) CD... I didn't build U-Boot from source... That's
> >something I'll need to take a look at...)
> >
> >Mike, have you discovered anything further about your problem?
> >
> >
> >
> >Walt
> >
> >
> >
> >On Tue, 2005-03-29 at 08:29 +0200, Bastos Fernandez Alexandre wrote:
> >
> >
> >>Hi,
> >>
> >>>From "linux/arch/ppc/platforms/pq2ads.h"
> >>#define BCSR_ADDR ((uint) 0xf4500000)
> >>>From "u-boot/include/configs/MPC8260ADS.h"
> >>#define CFG_BCSR 0xF4500000
> >>So ...
> >>Which version of u-boot and/or linux tree are you using?
> >>With linuxppc-2.5 and u-boot 1.2 everything works fine for me.
> >>Maybe Mike's problem is other. Maybe not. :-)
> >>
> >>Best regards,
> >>Alex
> >>
> >>
> >>
> >>>-----Original Message-----
> >>>From: Walter L. Wimer III [SMTP:walt.wimer@timesys.com]
> >>>Sent: Monday, March 28, 2005 6:07 PM
> >>>To: Mike Rapoport
> >>>Cc: linuxppc-embedded@ozlabs.org
> >>>Subject: Re: Problem running Linux 2.6.11 on MPC8272ADS
> >>>
> >>>
> >>>Hi Mike,
> >>>
> >>>I had the same "hang" experience. The file arch/ppc/platforms/pq2ads.c
> >>>contains the following function:
> >>>
> >>> void __init
> >>> m82xx_board_setup(void)
> >>> {
> >>> /* Enable the 2nd UART port */
> >>> *(volatile uint *)(BCSR_ADDR + 4) &= ~BCSR1_RS232_EN2;
> >>> }
> >>>
> >>>
> >>>I had to ifdef-out the assignment statement above. It appears that the
> >>>definition for BCSR_ADDR in the kernel code differs from what U-Boot is
> >>>using, and that area of memory isn't properly mapped into the kernel
> >>>address space this early in the boot sequence. As a result, I was
> >>>getting an Oops() before the console was even enabled (I could see the
> >>>Oops message by examining the kernel's printk log buffer using a
> >>>BDI-2000 hardware debugger).
> >>>
> >>>
> >>>
> >>>Good luck,
> >>>
> >>>Walt Wimer
> >>>TimeSys Corporation
> >>>
> >>>
> >>>
> >>>
> >>>On Sun, 2005-03-27 at 11:31 +0200, Mike Rapoport wrote:
> >>>
> >>>
> >>>>Hi,
> >>>>I'm trying to bring up the Linux 2.6.11 on MPC8272ADS and it seem to
> >>>>hang up at the very beginning.
> >>>>I use ads8272_defconfig and then enable console on SCC:
> >>>>
> >>>>CONFIG_SERIAL_CPM=y
> >>>>CONFIG_SERIAL_CPM_CONSOLE=y
> >>>>CONFIG_SERIAL_CPM_SCC1=y
> >>>>
> >>>>
> >>>>when I boot the kernel from the u-boot the system hangs up right after
> >>>>the kernel decompression.
> >>>>
> >>>>
> >>>>
> >>>_______________________________________________
> >>>Linuxppc-embedded mailing list
> >>>Linuxppc-embedded@ozlabs.org
> >>>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> >>>
> >>>
> >
> >
> >
> >
>
^ permalink raw reply
* Re: Platform bus/ppc sys model...
From: Kumar Gala @ 2005-03-30 15:06 UTC (permalink / raw)
To: Andrei Konovalov; +Cc: Sylvain Munaut, Jakob Viketoft, Linux PPC Embedded list
In-Reply-To: <424AAF09.9050706@ru.mvista.com>
On Mar 30, 2005, at 7:52 AM, Andrei Konovalov wrote:
> Sylvain Munaut wrote:
> > Hi,
> >
> >
> >> Is there some good documentation about how to use the platform bus=20=
> / ppc
> >> sys model or is it only possible to read and try to understand the=20=
> code
> >> for the freescale devices?
> >
> >
> > I'm not aware on documentation for the ppc_sys model in particular=20=
> but
> > the code is pretty easy to understand/read.
> >
> > Basically you have a ???_devices.c that describe all the devices you=20=
> can
> > find in a family of devices (by family I mean basically the same
> > processors but with slightly different options/peripheral), then a
> > ???_sys.c that describe each particular variant with the devices =
that
> > are really implemented in that variant). Then somewhere in platform=20=
> init
> > code, you need to identify the ppc system=A0 you're runngin on ( by =
a
> > identify_ppc_sys_by_id(mfspr(SPRN_SVR)); for e.g. ).
> >
> > Kumar, if I got it wrong, please correct ;)
thats a pretty fair description.
> Do I understand correct that the ppc_sys model used by 85xx, 83xx, and=20=
> 52xx
> SOCs is not so well suited for Virtex-II Pro (which Jakob and me bear=20=
> in mind)?
> In case of Xilinx ???_devices.c could be the list of all the IPs=20
> supported in linux.
> But ???_sys.c has little sense as for any given combination of the=20
> particular
> Virtex-II Pro chip and the particular board the set of IPs (as well=20=
> as the memory
> map, interrupt numbers, some hardware options (if ethernet has SGDMA=20=
> or not))
> is not fixed. I.e. ideally we would need some kind of run time system=20=
> configuration
> instead of compiled time system configuration implemented by=20
> ???_sys.c.
This is correct. There is nothing that precludes us from building up a=20=
way to dynamically create the information. Is there some way to query=20=
the hardware itself, or is the information implied something else?
- kumar
^ permalink raw reply
* Re: Platform bus/ppc sys model...
From: Andrei Konovalov @ 2005-03-30 13:52 UTC (permalink / raw)
To: Sylvain Munaut; +Cc: Linux PPC Embedded list, Jakob Viketoft
In-Reply-To: <424A7749.3040604@246tNt.com>
Sylvain Munaut wrote:
> Hi,
>
>
>> Is there some good documentation about how to use the platform bus / ppc
>> sys model or is it only possible to read and try to understand the code
>> for the freescale devices?
>
>
> I'm not aware on documentation for the ppc_sys model in particular but
> the code is pretty easy to understand/read.
>
> Basically you have a ???_devices.c that describe all the devices you can
> find in a family of devices (by family I mean basically the same
> processors but with slightly different options/peripheral), then a
> ???_sys.c that describe each particular variant with the devices that
> are really implemented in that variant). Then somewhere in platform init
> code, you need to identify the ppc system you're runngin on ( by a
> identify_ppc_sys_by_id(mfspr(SPRN_SVR)); for e.g. ).
>
> Kumar, if I got it wrong, please correct ;)
Do I understand correct that the ppc_sys model used by 85xx, 83xx, and 52xx
SOCs is not so well suited for Virtex-II Pro (which Jakob and me bear in mind)?
In case of Xilinx ???_devices.c could be the list of all the IPs supported in linux.
But ???_sys.c has little sense as for any given combination of the particular
Virtex-II Pro chip and the particular board the set of IPs (as well as the memory
map, interrupt numbers, some hardware options (if ethernet has SGDMA or not))
is not fixed. I.e. ideally we would need some kind of run time system configuration
instead of compiled time system configuration implemented by ???_sys.c.
Thanks,
Andrei
>> Specifically, how do you make the kernel aware of a certain device and
>> what else is required? Do I have to "connect" the device and the driver
>> or will the new model find this out automagically? I'm looking at
>> adding the usual serials, emacs etc...
>
>
> It's "automatic" by using matching of strings. The driver name has to be
> the same as the device name. More specifically by matching the name
> field in struct platform_device with the name field in struct
> device_driver. The code for this magic is in drivers/base/platform.c
>
>
>> Lastly, I suppose this will be the way all platforms should connect
>> their boards with the devices "from now on", right?
>
>
> It seems to be the trend yes.
> The OCP and platform bus model have the same base idea/concept. The
> advantage of platform bus is that it's common in multiple arch, the rest
> is mainly style. The ppc sys model is based on platform bus to ease
> working with SoC variants.
>
>
>
> Sylvain.
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: gcc-3.3.3 ppc e500 - Abort of uic from Qt (solved)
From: Clemens Koller @ 2005-03-30 12:57 UTC (permalink / raw)
To: James E Wilson; +Cc: gcc, linuxppc-embedded
In-Reply-To: <424A1936.9020309@specifixinc.com>
Just FYI x-posted to linuxppc-embedded
Hello, James!
Thank you for your hints...
In the meanwhile as I experienced some other strange issues with my
gcc-3.3.3 toolchain, I concentrated to upgrade to the latest
mainstream gcc-3.4.3. It also failed during bootstrapping in
the beginning, but after a 'two-iteration' bootstrap I was able
to move up to 3.4.3:
Here is my buildlog:
./gcc-3.4.3/configure
--enable-languages=c
--enable-shared
--enable-threads=posix
--enable-__cxa_atexit
--enable-nls=yes
--enable-clocale=gnu
make bootstrap
failed with an occasional segfault but let's give it a second chance
make bootstrap
which finished successful!
make install
Ok, now I have a working gcc-3.4.3 at least - well, for c only!
but let me now try a
make distclean
../gcc-3.4.3/configure
--enable-languages=c,c++,objc
--enable-shared
--enable-threads=posix
--enable-__cxa_atexit
--enable-nls=yes
--enable-clocale=gnu
make bootstrap
and voila! successful!
make check
make install
Okay, now, I am back to installing Qt... which also works fine.
uic doesn't crash anymore.
I am pretty sure that my initial toolchain (ELDK3.1 for ppc_8xx)
was somehow broken.
The next step is to get optimized code for the mpc8540 but that's low
priority now.
Best greets,
--
Clemens Koller
_______________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Str. 45/1
81379 Muenchen
Germany
http://www.anagramm.de
Phone: +49-89-741518-50
Fax: +49-89-741518-19
>> /[..]/qt-x11-free-3.3.4/bin/uic -L /[..]/qt-x11-free-3.3.4/plugins
>> -embed designercore [lots of images/*.png's]
>> -o qmake_image_collection.cpp
>> make: *** [qmake_image_collection.cpp] Aborted
>> make: *** Deleting file `qmake_image_collection.cpp'
>
>
> uic is dumping core. We can't really do anything about that, as that
> isn't part of gcc. We need a testcase that we can use to reproduce the
> problem, or evidence of an actual gcc problem.
>
> If this is a gcc miscompilation problem, and you are compiling with a
> high optimization level like -O2, you could try using -O or -O0 instead.
>
> You could try using a different gcc version. Maybe gcc-3.3.4 has a bug
> that isn't present in other earlier or later gcc-3.3.x versions.
>
> You could try debugging uic to figure out why it is failing.
>
> >BTW: What are the most current versions for a toolchain which
> generates >working and efficient code for the MPC8540 (ppc32, e500, spe)?
>
> There are people supporting the e500 target, so it should be working
> reasonably well in any gcc release.
>
> There is a special branch maintained for the e500 by Red Hat, which is
> called gcc-3_4-e500-branch. This can be checked out from our cvs
> repository. I don't know details about this branch other than what is
> on the web site.
> http://gcc.gnu.org/cvs.html#devbranches
> and scroll down to the Architecture-specific section.
^ permalink raw reply
* custom board MPC8266
From: Manisha Jagadhane @ 2005-03-30 11:32 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
I am using custom board based on MPC8266 processor. I have
successfully ported U-Boot 1.1.1 on it. I have used SMC1 as serial
port in the board. Does the 2.4.24 kernel version for ppc supports
SMC1 as serial console? Which configuration I have to give in the
.config file to configure SMC1 as serial console? Which board's
defconfig file shall I take as a reference and which kernel version
shall I use?
Please help me in this regard.
Thanking you in advance.
Regards,
Manisha.
^ permalink raw reply
* RE: Overcommit (OOM) problem on embedded device (PPChameleon)
From: Per Hallsmark @ 2005-03-30 10:30 UTC (permalink / raw)
To: linuxppc-embedded, Martin Egholm Nielsen
I think your main problem is that the stock 2.4.x kernel doesn't support
ovecommit_memory type 2 (i believe)...
Look in mm/mmap.c and search for overcommit_memory, then do same
in the sources for your redhat kernels.
Perhaps there's a patch for it floating around somewhere? ;-)
>===== Original Message From Martin Egholm Nielsen <martin@egholm-nielsen.dk>
=====
>Hi there,
>
>I hope this is the place to go...
>
>I have a some problems figuring out the OOM-killer and configuring the
>overcommit_memory parameter. Hope someone here can guide me in the right
>directions...
>
>Specs:
>I'm having an embedded Linux system running on a PPC405EP (PPChameleon)
>with 64 megs of RAM, some flash, but (ofcourse) no swap space. It runs a
>2.4.20 kernel patched with drivers for my device.
>
>Problem:
>I have an application that is killed by the OOM (I guess) when it tries
>to "use" more memory than present on the system.
>Bolied down, memory is allocated with "sbrk" and then touch'ed (see
>test-application below).
>
>With "/proc/sys/vm/overcommit_memory" set to 2, I expected that "sbrk"
>would return "-1L" (0xFFFFFFFF), but it doesn't, hence is
>terminated/killed by the kernel.
>
>However, both my desktop Linux (RH 7.3)/2.4.18-10/i386 and Linux
>(FC2)/2.6.5/i386 did what I expected:
>
># ./exhaust_mem
>...
>ffffffff
>
>Out of memory
># #Yeaaaah!
>
>Having searched the web, I see that this may be related with the fact
>that there is no swap enabled on the embedded device.
>However, I tried disabling the swap (commented in fstab), but the
>desktop linux still behaves "correct".
>
>Can I do anything in order to get it the way I expected?
>
>Best regards,
> Martin Egholm
>
>=== exhaust_mem.c ===
>
>#include <unistd.h>
>#include <stdio.h>
>#define SIZE 1000000
>
>int main( int i )
>{
> while ( 1 ) {
> char *v = sbrk( SIZE );
> char *p;
>
> printf( "%x\n\n", v );
>
> if ((long)v < 0) {
> fprintf(stderr, "Out of memory\n");
> exit(1);
> } // if
>
> for (p = v; p < v + SIZE; ++p) {
> *p = 42;
> } // for
>
> } // while
>} // main
>
>
>
>
>
>
>_______________________________________________
>Linuxppc-embedded mailing list
>Linuxppc-embedded@ozlabs.org
>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: [PATCH 4/91] get rid of pci_find_{device,subsys} arch/ppc
From: Amit Gud @ 2005-03-30 10:19 UTC (permalink / raw)
To: Amit Gud; +Cc: greg, paulus, linuxppc-dev
In-Reply-To: <ITPXCHFE1Uo1RZEpFid0000206a@itpxchfe1.enterprise.veritas.com>
Amit Gud wrote:
> replace pci_find_{device,subsys} with pci_get_{device,subsys}
>
Please don't apply, its incorrect.
Sorry for the inconvenience.
Best,
AG
--
May the source be with you.
^ permalink raw reply
* Re: Platform bus/ppc sys model...
From: Sylvain Munaut @ 2005-03-30 9:54 UTC (permalink / raw)
To: Jakob Viketoft; +Cc: Linux PPC Embedded list
In-Reply-To: <424A5C89.2030504@bitsim.se>
Hi,
> Is there some good documentation about how to use the platform bus / ppc
> sys model or is it only possible to read and try to understand the code
> for the freescale devices?
I'm not aware on documentation for the ppc_sys model in particular but
the code is pretty easy to understand/read.
Basically you have a ???_devices.c that describe all the devices you can
find in a family of devices (by family I mean basically the same
processors but with slightly different options/peripheral), then a
???_sys.c that describe each particular variant with the devices that
are really implemented in that variant). Then somewhere in platform init
code, you need to identify the ppc system you're runngin on ( by a
identify_ppc_sys_by_id(mfspr(SPRN_SVR)); for e.g. ).
Kumar, if I got it wrong, please correct ;)
> Specifically, how do you make the kernel aware of a certain device and
> what else is required? Do I have to "connect" the device and the driver
> or will the new model find this out automagically? I'm looking at adding
> the usual serials, emacs etc...
It's "automatic" by using matching of strings. The driver name has to be
the same as the device name. More specifically by matching the name
field in struct platform_device with the name field in struct
device_driver. The code for this magic is in drivers/base/platform.c
> Lastly, I suppose this will be the way all platforms should connect
> their boards with the devices "from now on", right?
It seems to be the trend yes.
The OCP and platform bus model have the same base idea/concept. The
advantage of platform bus is that it's common in multiple arch, the rest
is mainly style. The ppc sys model is based on platform bus to ease
working with SoC variants.
Sylvain.
^ permalink raw reply
* PSIM help
From: Anchor @ 2005-03-30 9:17 UTC (permalink / raw)
To: inuxppc-embedded
Hi erverbody:
I want build a PPC simulaiton system use PSIM, and I don't know how
to build a device tree file,
because I only want build com, memory, nvram, 4*nic, the cpu type is
MPC8245. please give me a
hand, give a sample file or a user guide to how to build it.
so many thanks!!
anchor xie
03-30-2005
^ permalink raw reply
* Platform bus/ppc sys model...
From: Jakob Viketoft @ 2005-03-30 8:00 UTC (permalink / raw)
To: Linux PPC Embedded list
Hello everyone!
This is a mail I sent to Kumar Gala, but as he rightly pointed out that
more people might benefit from the information and contribute to it, I
send it to the list instead.
Is there some good documentation about how to use the platform bus / ppc
sys model or is it only possible to read and try to understand the code
for the freescale devices?
Specifically, how do you make the kernel aware of a certain device and
what else is required? Do I have to "connect" the device and the driver
or will the new model find this out automagically? I'm looking at adding
the usual serials, emacs etc...
Lastly, I suppose this will be the way all platforms should connect
their boards with the devices "from now on", right?
Cheers!
/Jakob
^ permalink raw reply
* Re: ptrace and ORIG_EAX on ppc
From: Brad Boyer @ 2005-03-30 7:25 UTC (permalink / raw)
To: ashwin tanugula; +Cc: linuxppc-dev
In-Reply-To: <838f7c50050329170146631318@mail.gmail.com>
On Tue, Mar 29, 2005 at 08:01:06PM -0500, ashwin tanugula wrote:
> Hi!
> Can somebody tell me how to set references to ORIG_EAX in ppc kernel.
> We know ORIG_EAX is defined in unistd.h of i386. How do i make the
> following program print two same pids in ppc?
The ORIG_EAX is a reference to a register as saved in the stack. The
equivalent on ppc would seem to be PT_ORIG_R3. You're digging around
in an area that is extremely non-portable. This program appears to
be messing around with the syscall number before dispatch in the
syscall table. The implementation of ptrace on ppc and ppc64
explicitly does not allow changing this value, so I think you'll need
to find a completely different way to achieve your desired result.
Just to lessen the confusion, what are you trying to accomplish? Not
in the low-level detail sense, but what is the big picture goal?
Brad Boyer
flar@allandria.com
^ permalink raw reply
* [PATCH] MPC8555 CPM2 size/pointers for FCCs aka "All-ones problem"
From: Stefan Nickl @ 2005-03-30 7:44 UTC (permalink / raw)
To: Kumar Gala, Andrew Morton; +Cc: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 784 bytes --]
I've seen that MPC8555 support also made it into linux-2.6 by now.
I don't have hardware and time to test, but it looks like this bug has
made it over from the linuxppc-2.4 tree. The 8541/8555 has a smaller CPM
DPRAM than the standard CPM2, just like the 8272.
Unfortunately, the manual recommends you to use a segment of CPM DPRAM
that is not implemented in the 8541/55. If the smaller DPRAM is not
taken into account, fcc_enet.c will initialise the internal CPM buffer
pointers (fcc_riptr/fcc_tiptr) to invalid offsets, with the result that
all the FCC will ever send and receive are 0xff-en.
See also "All-ones problem with FCC1 on MPC8541" ~October 2004 on
linuxppc-embedded.
Signed-off-by: Stefan Nickl <Stefan.Nickl@kontron.com>
--
Stefan Nickl
Kontron Modular Computers
[-- Attachment #2: cpm2_8555.patch --]
[-- Type: text/x-patch, Size: 451 bytes --]
--- linux-2.5/include/asm-ppc/cpm2.h.old 2005-03-30 08:49:54.000000000 +0200
+++ linux-2.5/include/asm-ppc/cpm2.h 2005-03-30 08:56:07.000000000 +0200
@@ -86,7 +86,7 @@
*/
#define CPM_DATAONLY_BASE ((uint)128)
#define CPM_DP_NOSPACE ((uint)0x7fffffff)
-#ifdef CONFIG_8272
+#if defined(CONFIG_8272) || defined(CONFIG_MPC8555)
#define CPM_DATAONLY_SIZE ((uint)(8 * 1024) - CPM_DATAONLY_BASE)
#define CPM_FCC_SPECIAL_BASE ((uint)0x00009000)
#else
^ permalink raw reply
* [PATCH] ppc32: Fix MPC8555 & MPC8555E device lists (updated)
From: Kumar Gala @ 2005-03-30 7:28 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, linuxppc-embedded
Andrew,
(As I decide how long to keep the paper bag on this time, here is an
updated patch. This one actually reduces the number of devices as well as
removes the device from the lists which makes things work better :)
Removed the FCC3 device from the lists of devices on MPC8555 & MPC8555E
since it does not exist on these processors.
Signed-off-by: Jason McMullan <jason.mcmullan@timesys.com>
Signed-off-by: Kumar Gala <kumar.gala@freescale.com>
---
diff -Nru a/arch/ppc/syslib/mpc85xx_sys.c b/arch/ppc/syslib/mpc85xx_sys.c
--- a/arch/ppc/syslib/mpc85xx_sys.c 2005-03-30 01:23:14 -06:00
+++ b/arch/ppc/syslib/mpc85xx_sys.c 2005-03-30 01:23:14 -06:00
@@ -80,7 +80,7 @@
.ppc_sys_name = "8555",
.mask = 0xFFFF0000,
.value = 0x80710000,
- .num_devices = 20,
+ .num_devices = 19,
.device_list = (enum ppc_sys_devices[])
{
MPC85xx_TSEC1, MPC85xx_TSEC2, MPC85xx_IIC1,
@@ -88,7 +88,7 @@
MPC85xx_PERFMON, MPC85xx_DUART,
MPC85xx_CPM_SPI, MPC85xx_CPM_I2C, MPC85xx_CPM_SCC1,
MPC85xx_CPM_SCC2, MPC85xx_CPM_SCC3,
- MPC85xx_CPM_FCC1, MPC85xx_CPM_FCC2, MPC85xx_CPM_FCC3,
+ MPC85xx_CPM_FCC1, MPC85xx_CPM_FCC2,
MPC85xx_CPM_SMC1, MPC85xx_CPM_SMC2,
MPC85xx_CPM_USB,
},
@@ -97,7 +97,7 @@
.ppc_sys_name = "8555E",
.mask = 0xFFFF0000,
.value = 0x80790000,
- .num_devices = 21,
+ .num_devices = 20,
.device_list = (enum ppc_sys_devices[])
{
MPC85xx_TSEC1, MPC85xx_TSEC2, MPC85xx_IIC1,
@@ -105,7 +105,7 @@
MPC85xx_PERFMON, MPC85xx_DUART, MPC85xx_SEC2,
MPC85xx_CPM_SPI, MPC85xx_CPM_I2C, MPC85xx_CPM_SCC1,
MPC85xx_CPM_SCC2, MPC85xx_CPM_SCC3,
- MPC85xx_CPM_FCC1, MPC85xx_CPM_FCC2, MPC85xx_CPM_FCC3,
+ MPC85xx_CPM_FCC1, MPC85xx_CPM_FCC2,
MPC85xx_CPM_SMC1, MPC85xx_CPM_SMC2,
MPC85xx_CPM_USB,
},
^ permalink raw reply
* Re: [PATCH] ppc32: CPM2 PIC cleanup irq_to_siubit array
From: Kumar Gala @ 2005-03-30 4:20 UTC (permalink / raw)
To: Dan Malek
Cc: Andrew Morton, shall, linux-kernel, Kumar Gala, linuxppc-embedded
In-Reply-To: <84ab51297f043a761321ee6eddc43d4a@embeddededge.com>
Done, updated patch w/comment sent to Andrew.
- kumar
On Mar 29, 2005, at 7:10 PM, Dan Malek wrote:
>
>
> On Mar 29, 2005, at 5:30 PM, Kumar Gala wrote:
>
> > Cleaned up irq_to_siubit array so we no longer need to do 1 <<
> > (31-bit),
> > just 1 << bit.
>
> Will you please put a comment in here that indicates this array now
> has this computation done?=A0 When I wrote it, these bit numbers
> matched the registers and the documentation, so I didn't take
> the time to explain. :-)
>
> Thanks.
>
>
>
> =A0=A0=A0=A0=A0=A0=A0 -- Dan
^ permalink raw reply
* [PATCH] ppc32: CPM2 PIC cleanup irq_to_siubit array (updated)
From: Kumar Gala @ 2005-03-30 4:19 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, linuxppc-embedded
Andrew,
(Updated this patch to include a comment at Dan Malek's request.)
Cleaned up irq_to_siubit array so we no longer need to do 1 << (31-bit),
just 1 << bit.
Signed-off-by: Kumar Gala <kumar.gala@freescale.com>
---
diff -Nru a/arch/ppc/syslib/cpm2_pic.c b/arch/ppc/syslib/cpm2_pic.c
--- a/arch/ppc/syslib/cpm2_pic.c 2005-03-29 22:15:24 -06:00
+++ b/arch/ppc/syslib/cpm2_pic.c 2005-03-29 22:15:24 -06:00
@@ -32,15 +32,17 @@
0, 0, 0, 0, 0, 0, 0, 0
};
+/* bit numbers do not match the docs, these are precomputed so the bit for
+ * a given irq is (1 << irq_to_siubit[irq]) */
static u_char irq_to_siubit[] = {
- 31, 16, 17, 18, 19, 20, 21, 22,
- 23, 24, 25, 26, 27, 28, 29, 30,
- 29, 30, 16, 17, 18, 19, 20, 21,
- 22, 23, 24, 25, 26, 27, 28, 31,
- 0, 1, 2, 3, 4, 5, 6, 7,
- 8, 9, 10, 11, 12, 13, 14, 15,
- 15, 14, 13, 12, 11, 10, 9, 8,
- 7, 6, 5, 4, 3, 2, 1, 0
+ 0, 15, 14, 13, 12, 11, 10, 9,
+ 8, 7, 6, 5, 4, 3, 2, 1,
+ 2, 1, 15, 14, 13, 12, 11, 10,
+ 9, 8, 7, 6, 5, 4, 3, 0,
+ 31, 30, 29, 28, 27, 26, 25, 24,
+ 23, 22, 21, 20, 19, 18, 17, 16,
+ 16, 17, 18, 19, 20, 21, 22, 23,
+ 24, 25, 26, 27, 28, 29, 30, 31,
};
static void cpm2_mask_irq(unsigned int irq_nr)
@@ -54,7 +56,7 @@
word = irq_to_siureg[irq_nr];
simr = &(cpm2_immr->im_intctl.ic_simrh);
- ppc_cached_irq_mask[word] &= ~(1 << (31 - bit));
+ ppc_cached_irq_mask[word] &= ~(1 << bit);
simr[word] = ppc_cached_irq_mask[word];
}
@@ -69,7 +71,7 @@
word = irq_to_siureg[irq_nr];
simr = &(cpm2_immr->im_intctl.ic_simrh);
- ppc_cached_irq_mask[word] |= (1 << (31 - bit));
+ ppc_cached_irq_mask[word] |= 1 << bit;
simr[word] = ppc_cached_irq_mask[word];
}
@@ -85,9 +87,9 @@
simr = &(cpm2_immr->im_intctl.ic_simrh);
sipnr = &(cpm2_immr->im_intctl.ic_sipnrh);
- ppc_cached_irq_mask[word] &= ~(1 << (31 - bit));
+ ppc_cached_irq_mask[word] &= ~(1 << bit);
simr[word] = ppc_cached_irq_mask[word];
- sipnr[word] = 1 << (31 - bit);
+ sipnr[word] = 1 << bit;
}
static void cpm2_end_irq(unsigned int irq_nr)
@@ -103,7 +105,7 @@
word = irq_to_siureg[irq_nr];
simr = &(cpm2_immr->im_intctl.ic_simrh);
- ppc_cached_irq_mask[word] |= (1 << (31 - bit));
+ ppc_cached_irq_mask[word] |= 1 << bit;
simr[word] = ppc_cached_irq_mask[word];
}
}
^ permalink raw reply
* How does the Montavisa previewkit?
From: likun @ 2005-03-30 1:43 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 649 bytes --]
Hi everbody:
i downloaded a Montavisa previewkit-mvl3.0.0_db1500-encrypt.img
yesterday ,it's a free kit.i want to use it as my hard hat linux .i work
on muti channels MPEG4 video process ,need OS strong real time,i kown the
vxworks being very good,but it's very expencive.so i had to use Embed
linux on mips-au1500 cpu.what i want to know is how does the real time of
Montavisa previewkit
,anybody know?
for example, i want to deal with 16-24 channel MPEG4 codec
using MPEG4 ASIC chip .enviroment is Red hat 7.2 kenel 2.4.20.
can the Montavisa response real time?
thank all
jordon
[-- Attachment #2: Type: text/html, Size: 1135 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox