Overcommit (OOM) problem on embedded device (PPChameleon)
Hi David,
>>>Look in mm/mmap.c and search for overcommit_memory, then do same
>>>in the sources for your redhat kernels.
>>I'll look into RH kernel to see if it isn't like you say :-)
>>>Perhaps there's a patch for it floating around somewhere? ;-)
>>Now, that would be really nice.
>>Though I have no idea of where to look!?
> Here is what I do. Patch is against BK linuxppc-2.4 version 1.1285
> (2.4.28-pre3) but might work.
Well, the patch goes straight into my 2.4.20 ppc-kernel - but we have to
wait until tomorrow to see if it does the magic.
> Burns 5% of the RAM but alternatives all seem worse and I never
I can live with that (3%)...
> If you find out why RH works it would be interesting ... perhaps
> there is a better way.
I downloaded the 2.4.20-10 kernel SRPM from RH8 - it contains all the
patches they apply to the serene 2.4.20 kernel.
There is some stuff regarding introducing the
"overcommit_memory_accounting" variable from the 2.5 kernel, but I
haven't looked into it in depth.
I'll try with your patch first :-)
BR,
Martin Egholm
> #
> # mm/mmap.c
> # Add pessimistic overcommit mode similar to 2.6 mode 2.
> # This allows malloc aka sbrk() to actually fail before
> # process is killed.
> # Overloaded sysctl_overcommit_memory to be both enable
> # and ratio to avoid making a new sysctl.
> #
> diff -Nru a/mm/mmap.c b/mm/mmap.c
> --- a/mm/mmap.c 2005-03-30 07:15:13 -08:00
> +++ b/mm/mmap.c 2005-03-30 07:15:13 -08:00
> @@ -45,9 +45,13 @@
> __S000, __S001, __S010, __S011, __S100, __S101, __S110, __S111
> };
>
> -int sysctl_overcommit_memory;
> +int sysctl_overcommit_memory = 98;
> +
> int max_map_count = DEFAULT_MAX_MAP_COUNT;
>
> +extern unsigned long totalram_pages;
> +extern unsigned long totalhigh_pages;
> +
> /* Check that a process has enough memory to allocate a
> * new virtual mapping.
> */
> @@ -66,7 +70,7 @@
> unsigned long free;
>
> /* Sometimes we want to use more memory than we have. */
> - if (sysctl_overcommit_memory)
> + if (sysctl_overcommit_memory == 1)
> return 1;
>
> /* The page cache contains buffer pages these days.. */
> @@ -91,7 +95,20 @@
> free += (dentry_stat.nr_unused * sizeof(struct dentry)) >>
> PAGE_SHIFT;
> free += (inodes_stat.nr_unused * sizeof(struct inode)) >>
> PAGE_SHIFT;
>
> + /*
> + * Leave the last 3% for root
> + */
> + if (current->euid)
> + free -= free / 32;
> +
> + /* Strict mode do not allocate last bit of memory */
> + if (sysctl_overcommit_memory) {
> + pages += (totalram_pages - totalhigh_pages)
> + * (100 - sysctl_overcommit_memory) / 100;
> + }
> +
> return free > pages;
> +
> }
>
> /* Remove one vm structure from the inode's i_mapping address space. */
>
>
>
Linux crashes during memory mapping
7369673af bad area, sig: 00178254: 2031310a 3c343e4e 49503a20 30303030 11.<4>NIP: 00178264: 30303031 20584552 3a203030 303030300001 XER: 00 00178274: 3030204c 523a2043 30313530 3044302000 LR: C01500D0 00178284: 53503a20 46464646 46434330 20524547SP: FCC0 REG 00178294: 533a2063 30313530 30303020 54524150S: c015 TRAP 001782a4: 3a203130 33322020 20204e6f 74207461: 1032Not ta 001782b4: 696e7465 640a3c34 3e4d5352 3a20inted.<4>MSR: ff 001782c4: 2045 453a2031 2050523aff EE: 1 PR: 001782d4: 20312046 503a2031 204d453a 20312049 1 FP: 1 ME: 1 I 001782e4: 522f4452 3a203131 0a3c343e 5441534bR/DR: 11.<4>TASK 001782f4: 203d2063 30313466 3437305b 305d2027 = c014f470[0] ' 00178304: 73772720 4c617374 20737973 63616c6csw' Last syscall 00178314: 3a202d31 30373337 31383034 30200a3c: -1073718040 .< 00178324: 343e6c61 7374206d 61746820 303030304>last math 00178334: 30303030 206c6173 7420616c 74697665 last altive 00178344: 63203030 30303030 30300a3c 343ec .<4>.. 00178354: c015 02c0c015 0200 4. Below is our register values: HRCW0x0c42020a IMMR0xF000 SYPCR 0x0681 SCCR0x0001 RMR 0x BCR 0x0010 HID00xcc88 /*Initial*/ HID00x8008 /*Final*/ # Flash - CS0 BR0 0xFe001801 OR0 0xFe000880 # SDRAM - CS1 OR1 0xFE002EC0 BR1 0x0041 PSRT0x27 MPTPR 0x2500 # cbr refresh PSDMR 0xC24A24A2 SIUMCR 0x01230200 MSR 0xB942 Awaiting prompt reply, Atit -Original Message- From: Steven Blakeslee [mailto:[EMAIL PROTECTED] Sent: Thursday, March 31, 2005 6:23 PM To: Atit_Shah; linuxppc-embedded at ozlabs.org Subject: RE: Linux crashes during memory mapping > I do not have any problem with the functioning of U-Boot but Linux crashes after > printing "Uncompressing Kernel ... OK" and then it seems that nothing is happening. Do you have the SYPCR(serial watch dog timer) disabled? > 3. The memory map of the VPN Board (MY BOARD) is as folllows: > = > Memory RegionSize Address Range > == > SDRAM32MByte _ -- 01FF_ > Flash32MByte FF00_ -- _ Have you done a full test to make sure your RAM is correctly mapped? > This is what the console log buffer has shown: > = > md 0x00177e34 > > 00177e34: 3c363e6d 73746172 743d303c 363e6d73 <6>mstart=0<6>ms > 00177e44: 697a653d 303c363e 66737461 72743d30 ize=0<6>fstart=0 > 00177e54: 3c363e66 73697a65 3d303c36 3e696d6d <6>fsize=0<6>imm > 00177e64: 723d303c 363e626f 74666c61 673d303c r=0<6>botflag=0< > 00177e74: 363e6970 6164643d 303c363e 65616464 6>ipadd=0<6>eadd > 00177e84: 3d633031 35303032 383c363e 65737065 =c0150028<6>espe > 00177e94: 643d303c 363e696e 6974663d 303c363e d=0<6>initf=0<6> > 00177ea4: 62757366 3d303c36 3e63706d 663d303c busf=0<6>cpmf=0< > 00177eb4: 363e6272 67663d30 3c363e73 6363663d 6>brgf=0<6>sccf= > 00177ec4: 303c363e 76636f3d 303c363e 62617564 0<6>vco=0<6>baud > 00177ed4: 3d304f6f 70733a20 6b65726e 656c2061=0Oops: kernel a These values do not look correct. Everything is zero. ** This email (including any attachments) is intended for the sole use of the intended recipient/s and may contain material that is CONFIDENTIAL AND PRIVATE COMPANY INFORMATION. Any review or reliance by others or copying or distribution or forwarding of any or all of the contents in this message is STRICTLY PROHIBITED. If you are not the intended recipient, please contact the sender by email and delete all copies; your cooperation in this regard is appreciated. ** -- next part -- An HTML attachment was scrubbed... URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050331/cdedc379/attachment.htm
service outage
Hi all, There will be a (hopefully short) service disruption tomorrow (Friday April 1) at 1pm Canberra time (3 am UTC) to these mailing lists and the ozlabs.org web site while our hosting ISP changes upstream service provider. -- Cheers, Stephen Rothwellsfr at canb.auug.org.au http://www.canb.auug.org.au/~sfr/ -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050331/8e26a16f/attachment.pgp
Linux for the Xilinx Memec V2P20-1152
Has anyone built an image for the Memec 1152 V2P board? I downloaded the linuxppc bitkeeper, but it seems to want to build an i386 version. Havent figured out a config that gets me a useableimage.Can anyone send me a config file that compiles? Thanks Tracey
440EP FPU patch
On Thu, 2005-03-31 at 13:10 -0700, Matt wrote: > > If nobody has time to work on this, then I intend to put Wade's 440EP > support in as is (actually, he's planning on resubmitting with some > additional changes). When somebody has time, they can redo the patch > against that. Do those changes happen to include the MTD driver for the NAND controller? Wade, any word on that? josh
440EP FPU patch
I'll try to see if I can build a kernel to use on a pegasos box to test out the avec side tomorrow. - kumar On Mar 31, 2005, at 2:15 PM, Tom Rini wrote: > On Thu, Mar 31, 2005 at 01:10:44PM -0700, Matt wrote: > > On Thu, Mar 31, 2005 at 09:34:21AM -0700, Tom Rini wrote: > > > On Thu, Mar 31, 2005 at 09:26:18AM -0700, Wade Farnsworth wrote: > > > > On Fri, 2005-03-18 at 12:30, Tom Rini wrote: > > > > > On Fri, Mar 18, 2005 at 01:43:11PM -0500, Jason McMullan > wrote: > > > > > > On Fri, 2005-03-18 at 10:06 -0600, Kumar Gala wrote: > > > > > > > Can you build your patch for the lopec_defconfig and fix > the errors > > > > > > > associated with enabling altivec. > > > > > > > > > > > > > > Looks like you need to include asm/offset.h & asm/page.h > in vector.S, > > > > > > > however there is another build error after that. > > > > > > > > > > > > Thanks! That also found a linking bug, fixed in this patch.. > Please > > > > > > double check the call in 'AltiVecUnavalible' in head.S, and > the re-load > > > > > > of 'ctr' at the end of load_up_altivec, as I do not have an > AltiVec > > > > > > machine here. > > > > > > > > > > No dice: > > > > > VFS: Mounted root (nfs filesystem) readonly. > > > > > Freeing unused kernel memory: 100k init 4k prep > > > > > floating point used in kernel (task=c03816b0, pc=c000d664) > > > > > Doing some objdump'ing, that's the start of load_up_altivec. > > > > > > > > Hi Jason and Tom, > > > > > > > > Has there been any more progress on this patch? > > > > > > Sadly no.? We got to the point where it was reliably crashing on my > > > LoPEC (7400), but no time to try and fix it.? The problem should > show up > > > on any classic PPC box.. > > > > If nobody has time to work on this, then I intend? to put Wade's > 440EP > > support in as is (actually, he's planning on resubmitting with some > > additional changes).? When somebody has time, they can redo the > patch > > against that. > > That's a good point to bring up.? Jason, do you want to post your > current version to the list and we can try and see if we can get it > workign right? > > -- > Tom Rini > http://gate.crashing.org/~trini/ > ___ > Linuxppc-embedded mailing list > Linuxppc-embedded at ozlabs.org > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
[PATCH 2.6.10-rc2] ppc32: Add usb support to IBM stb04xxx platforms (v3)
Signed-off-by: Dale Farnsworth
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
#include
+#include
#include
static struct ocp_func_iic_data ibmstb4_iic0_def = {
@@ -72,12 +73,51 @@
.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,
}
};
+
+/* Polarity and triggering settings for internal interrupt sources */
+struct ppc4xx_uic_settings ppc4xx_core_uic_cfg[] __initdata = {
+ { .polarity = 0x7f01,
+ .triggering = 0x,
+ .ext_irq_mask = 0x007e, /* IRQ0 - IRQ5 */
+ }
+};
+
+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 = 0xULL;
+
+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 = 0xULL,
+ }
+};
+
+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 0x4000
#define GPIO0_BASE 0x4006
+#define USB0_BASE 0x4001
+#define USB0_SIZE 0xA0
#define USB0_IRQ 18
-#define USB0_BASE STB04xxx_MAP_IO_ADDR(0x4001)
-#define USB0_EXTENT 4096
#define IIC_NUMS 2
#define UART_NUMS 3
Index: linux-2.5-usb-405/arch/ppc/platforms/4xx/redwood5.c
===
--- linux-2.5-usb-405.orig/arch/ppc/platforms/4xx/redwood5.c
+++ linux-2.5-usb-405/arch/ppc/platforms/4xx/redwood5.c
@@ -18,6 +18,19 @@
#include
#include
#include
+#include
+
+/*
+ * Define external IRQ senses and polarities.
+ */
+unsigned char ppc4xx_uic_ext_irq_cfg[] __initdata = {
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* Ext Int 0 */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* Ext Int 1 */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* Ext Int 2 */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* Ext Int 3 */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* Ext Int 4 */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* Ext Int 5 */
+};
static struct resource smc91x_resources[] = {
[0] = {
[PATCH 2.6.10-rc2] ppc32: Add usb support to IBM stb04xxx platforms
On Thu, Mar 31, 2005 at 01:08:07PM -0800, Eugene Surovegin wrote: > Dale, please, don't mess with UIC registers directly, there is a > cleaner way to set this up. > > Take a look at how this is done in other 4xx ports > (ppc4xx_core_uic_cfg & ppc4xx_uic_ext_irq_cfg). Thanks for the heads up Eugene. I'll submit an updated patch shortly. -Dale
Problem running Linux 2.6.11 on MPC8272ADS
Good point. There is also IMMR need to be passed from bootloader to kernel. We can make more use of the u-boot bd_info mechanism. But it binds ppc linux to u-boot boot loader. I don't know if we should make it a porting convention. Best Regards, Leo > -Original Message- > From: Eugene Surovegin [mailto:ebs at ebshome.net] > Sent: Thursday, March 31, 2005 11:27 AM > To: Li Yang-r58472 > Cc: Walter L. Wimer III; Gala Kumar K.-galak; Linux PPC Embedded list > Subject: Re: Problem running Linux 2.6.11 on MPC8272ADS > > On Thu, Mar 31, 2005 at 11:03:00AM +0800, Li Yang-r58472 wrote: > > Well, it seems to be a historic problem. Freescale BSP was > > originally ported from u-boot-1.0.0 and linux-2.4.22. So the BCSR > > was freely chosen as 0xf800. Later, we updated them to > > u-boot-1.1.1 and linux-2.4.26, and make the BCSR consistent to older > > version. However the sourceforge u-boot-1.1.1 support for > > MPC8272ADS > > was committed by Arabella guys, they chose BCSR mapping to > > 0xf450. Kumar's MPC8272 support which is in 2.6.11 source was > > developed using sourceforge u-boot-1.1.1 seemingly. > > > > This might brought up a question that if we need a convention or > > something to define the recommended memory mapping for PowerPC BSPs. > > As there are different groups of people around the world developing > > BSPs for PowerPC platforms, and often the communication between them > > is very limited. > > > > For now using kernel and u-boot released from the same vendor is > > recommended. > > > > There is trivial solution which will work regardless on which version > of U-Boot and kernel you are using. > > DO NOT hardcode such stuff in TWO DIFFERENT places, do this only in > one, in this case it should be firmware (e.g. U-Boot). > > In kernel just read BRx register for that chip select and use this > address for accesses from the kernel. This is how I do on all my > board ports. > > No need to establish any artificial conventions on memory map, etc. > > -- > Eugene
[PATCH 2.6.11.6] CPM2 Timers API
A brown bag error handling and Lindent patch, to be applied in that order, to my previous CPM timers patch. -- Jason McMullan TimeSys Corporation -- next part -- A non-text attachment was scrubbed... Name: cpm-timer.brown-bag.patch Type: text/x-patch Size: 638 bytes Desc: not available Url : http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050331/31718842/attachment.bin -- next part -- A non-text attachment was scrubbed... Name: cpm-timer.lindent.patch Type: text/x-patch Size: 7152 bytes Desc: not available Url : http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050331/31718842/attachment-0001.bin -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050331/31718842/attachment.pgp
Header files for 440?
Hi, Are there any criteria to define things on so many different header files for 440 family chips? For example, an Ocotea board has the following header files. 1. 2. 3. 4. 5. I can understand the reasons why there are ibm44x.h, ibm440gx.h, and ocotea.h. But why do we need to separate ibm44x_common.h from ibm44x.h and ibm440gx.h from ibm440gx_common.h? Can we just simply combine them together? It's a little confusing on what definitions and declarations should be which files. Is there any guildeline saying what header file should be in , , or ? Any explanations? Thanks, -Shawn.
[PATCH 2.6.11.6] CPM2 Timers API
Two patches: cpm-timer.patch: The base timers API for CPM2 timers cpm-timer.mpc85xx-devices.patch: MPC85xx support -- Jason McMullan TimeSys Corporation -- next part -- A non-text attachment was scrubbed... Name: cpm-timer.mpc85xx-devices.patch Type: text/x-patch Size: 4739 bytes Desc: not available Url : http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050331/399f76d1/attachment.bin -- next part -- A non-text attachment was scrubbed... Name: cpm-timer.patch Type: text/x-patch Size: 16394 bytes Desc: not available Url : http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050331/399f76d1/attachment-0001.bin -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050331/399f76d1/attachment.pgp
[PATCH 2.6.10-rc2] ppc32: Add platform data definition used by ohci-ppc-soc.c
This structure allows for callbacks into platform-specific code when the
driver is started or stopped. This file is currently included by
drivers/usb/host/ohci-ppc-soc.c, so it's needed for USB on the stb04xxx,
mpc52xx, and 440EP.
Signed-off-by: Dale Farnsworth
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,13 @@
+/*
+ * ppc/usb.h:
+ *
+ */
+#ifndef _PPC_USB_H
+#define _PPC_USB_H
+
+struct usb_hcd_platform_data {
+ int (*start) (struct platform_device *pdev);
+ void (*stop) (struct platform_device *pdev);
+};
+
+#endif /* !(_PPC_USB_H) */
[PATCH 2.6.10-rc2] ppc32: Add usb support to IBM stb04xxx platforms
Signed-off-by: Dale Farnsworth
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
@@ -72,12 +72,43 @@
.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,
}
};
+
+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 = 0xULL;
+
+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 = 0xULL,
+ }
+};
+
+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 0x4000
#define GPIO0_BASE 0x4006
+#define USB0_BASE 0x4001
+#define USB0_SIZE 0xA0
#define USB0_IRQ 18
-#define USB0_BASE STB04xxx_MAP_IO_ADDR(0x4001)
-#define USB0_EXTENT 4096
#define IIC_NUMS 2
#define UART_NUMS 3
Index: linux-2.5-usb-405/arch/ppc/platforms/4xx/redwood5.c
===
--- linux-2.5-usb-405.orig/arch/ppc/platforms/4xx/redwood5.c
+++ linux-2.5-usb-405/arch/ppc/platforms/4xx/redwood5.c
@@ -52,8 +52,18 @@
void __init
redwood5_setup_arch(void)
{
+ u32 mask;
+
ppc4xx_setup_arch();
+ /*
+* Set up USB interrupt as positive polarity and level-sensitive.
+* Firmware should do this, but apparently does not.
+*/
+ 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);
+
#ifdef CONFIG_DEBUG_BRINGUP
printk("\n");
printk("machine\t: %s\n", PPC4xx_MACHINE_NAME);
Platform bus/ppc sys model - [Fwd: bi_recs and u-boot ppcboot.h]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, I hope Wolfgang doesn't mind me forwarding this :-) This is what I have some limited time for at the moment - but work takes priority! Cheers, Jon. - Original Message Subject: bi_recs and u-boot ppcboot.h Date: Fri, 11 Mar 2005 03:00:18 + From: Jon Masters <[EMAIL PROTECTED]> Organization: World Organi[sz]ation Of Broken Dreams To: Wolfgang Denk Hi Wolfgang, I'm looking at this bi_recs replacement again. Do you have any particular objection to me extending bd_info (at the end, only if CONFIG_FAKEOFTREE is selected) to add a pointer to a BLOB of fake OF device tree? Assuming not, I'm going to try to figure out how to do this in u-boot. Do you have a ppc405 board online at the moment with a BDI2000 OOI? I can't see one on pollux or xpert at the moment - if you've got one spare that can be made available at some point, please let me know. ( basically, I've got ppcboot on an old CPCI405 here but it's not trivial to fix if I break it and I don't know much about whether u-boot supports chaining in to a new u-boot loaded from within itself...but it probably does, I guess. Bah, it's late, I'm rambling...). Cheers, Jon. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCS+7NeTyyexZHHxERAsVkAJ9WK/eHANzVdMTiPVRneHVuitt5FgCeOJCE Oxf9aVCY4OG5+2kgmJfGgAw= =BF/h -END PGP SIGNATURE-
Platform bus/ppc sys model...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kumar Gala wrote: |> 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? This got resurrected recently. Some of us have been talking privately about it and I should have time with a board and BDI shortly. The idea above about the bd_info pointer is precisely what I've been working with people off list on. | 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? Yes, but I've been tied up with worky and magazine stuff again. If someone wants to work with me then this might actually happen. Cheers, Jon. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCS+38eTyyexZHHxERAhKmAJ9v2k8rvFjB+W9OmXu4P7blHiWIkQCglEFk AA2fZEsXmpWV0Jj/Z2OCrxA= =oVje -END PGP SIGNATURE-
440EP FPU patch
On Thu, Mar 31, 2005 at 01:10:44PM -0700, Matt wrote: > On Thu, Mar 31, 2005 at 09:34:21AM -0700, Tom Rini wrote: > > On Thu, Mar 31, 2005 at 09:26:18AM -0700, Wade Farnsworth wrote: > > > On Fri, 2005-03-18 at 12:30, Tom Rini wrote: > > > > On Fri, Mar 18, 2005 at 01:43:11PM -0500, Jason McMullan wrote: > > > > > On Fri, 2005-03-18 at 10:06 -0600, Kumar Gala wrote: > > > > > > Can you build your patch for the lopec_defconfig and fix the errors > > > > > > associated with enabling altivec. > > > > > > > > > > > > Looks like you need to include asm/offset.h & asm/page.h in > > > > > > vector.S, > > > > > > however there is another build error after that. > > > > > > > > > > Thanks! That also found a linking bug, fixed in this patch.. Please > > > > > double check the call in 'AltiVecUnavalible' in head.S, and the > > > > > re-load > > > > > of 'ctr' at the end of load_up_altivec, as I do not have an AltiVec > > > > > machine here. > > > > > > > > No dice: > > > > VFS: Mounted root (nfs filesystem) readonly. > > > > Freeing unused kernel memory: 100k init 4k prep > > > > floating point used in kernel (task=c03816b0, pc=c000d664) > > > > Doing some objdump'ing, that's the start of load_up_altivec. > > > > > > Hi Jason and Tom, > > > > > > Has there been any more progress on this patch? > > > > Sadly no. We got to the point where it was reliably crashing on my > > LoPEC (7400), but no time to try and fix it. The problem should show up > > on any classic PPC box.. > > If nobody has time to work on this, then I intend to put Wade's 440EP > support in as is (actually, he's planning on resubmitting with some > additional changes). When somebody has time, they can redo the patch > against that. That's a good point to bring up. Jason, do you want to post your current version to the list and we can try and see if we can get it workign right? -- Tom Rini http://gate.crashing.org/~trini/
440EP FPU patch
On Thu, Mar 31, 2005 at 09:34:21AM -0700, Tom Rini wrote: > On Thu, Mar 31, 2005 at 09:26:18AM -0700, Wade Farnsworth wrote: > > On Fri, 2005-03-18 at 12:30, Tom Rini wrote: > > > On Fri, Mar 18, 2005 at 01:43:11PM -0500, Jason McMullan wrote: > > > > On Fri, 2005-03-18 at 10:06 -0600, Kumar Gala wrote: > > > > > Can you build your patch for the lopec_defconfig and fix the errors > > > > > associated with enabling altivec. > > > > > > > > > > Looks like you need to include asm/offset.h & asm/page.h in vector.S, > > > > > however there is another build error after that. > > > > > > > > Thanks! That also found a linking bug, fixed in this patch.. Please > > > > double check the call in 'AltiVecUnavalible' in head.S, and the re-load > > > > of 'ctr' at the end of load_up_altivec, as I do not have an AltiVec > > > > machine here. > > > > > > No dice: > > > VFS: Mounted root (nfs filesystem) readonly. > > > Freeing unused kernel memory: 100k init 4k prep > > > floating point used in kernel (task=c03816b0, pc=c000d664) > > > Doing some objdump'ing, that's the start of load_up_altivec. > > > > Hi Jason and Tom, > > > > Has there been any more progress on this patch? > > Sadly no. We got to the point where it was reliably crashing on my > LoPEC (7400), but no time to try and fix it. The problem should show up > on any classic PPC box.. If nobody has time to work on this, then I intend to put Wade's 440EP support in as is (actually, he's planning on resubmitting with some additional changes). When somebody has time, they can redo the patch against that. -Matt
[PATCH 2.6.10-rc2] ppc32: Add usb support to IBM stb04xxx platforms
On Thu, Mar 31, 2005 at 01:47:30PM -0700, Dale Farnsworth wrote:
[snip]
> ===
> --- linux-2.5-usb-405.orig/arch/ppc/platforms/4xx/redwood5.c
> +++ linux-2.5-usb-405/arch/ppc/platforms/4xx/redwood5.c
> @@ -52,8 +52,18 @@
> void __init
> redwood5_setup_arch(void)
> {
> + u32 mask;
> +
> ppc4xx_setup_arch();
>
> + /*
> + * Set up USB interrupt as positive polarity and level-sensitive.
> + * Firmware should do this, but apparently does not.
> + */
> + 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);
> +
> #ifdef CONFIG_DEBUG_BRINGUP
> printk("\n");
> printk("machine\t: %s\n", PPC4xx_MACHINE_NAME);
Dale, please, don't mess with UIC registers directly, there is a
cleaner way to set this up.
Take a look at how this is done in other 4xx ports
(ppc4xx_core_uic_cfg & ppc4xx_uic_ext_irq_cfg).
--
Eugene
440EP FPU patch
Tom, On Mar 31, 2005, at 10:34 AM, Tom Rini wrote: > On Thu, Mar 31, 2005 at 09:26:18AM -0700, Wade Farnsworth wrote: > > On Fri, 2005-03-18 at 12:30, Tom Rini wrote: > > > On Fri, Mar 18, 2005 at 01:43:11PM -0500, Jason McMullan wrote: > > > > On Fri, 2005-03-18 at 10:06 -0600, Kumar Gala wrote: > > > > > Can you build your patch for the lopec_defconfig and fix the > errors > > > > > associated with enabling altivec. > > > > > > > > > > Looks like you need to include asm/offset.h & asm/page.h in > vector.S, > > > > > however there is another build error after that. > > > > > > > > Thanks! That also found a linking bug, fixed in this patch.. > Please > > > > double check the call in 'AltiVecUnavalible' in head.S, and the > re-load > > > > of 'ctr' at the end of load_up_altivec, as I do not have an > AltiVec > > > > machine here. > > > > > > No dice: > > > VFS: Mounted root (nfs filesystem) readonly. > > > Freeing unused kernel memory: 100k init 4k prep > > > floating point used in kernel (task=c03816b0, pc=c000d664) > > > Doing some objdump'ing, that's the start of load_up_altivec. > > > > Hi Jason and Tom, > > > > Has there been any more progress on this patch? > > Sadly no.? We got to the point where it was reliably crashing on my > LoPEC (7400), but no time to try and fix it.? The problem should show > up > on any classic PPC box.. Is it crashing on just avec code or everything? - kumar
440EP FPU patch
On Thu, Mar 31, 2005 at 12:45:44PM -0600, Kumar Gala wrote: > Tom, > > On Mar 31, 2005, at 10:34 AM, Tom Rini wrote: > > >On Thu, Mar 31, 2005 at 09:26:18AM -0700, Wade Farnsworth wrote: > > > On Fri, 2005-03-18 at 12:30, Tom Rini wrote: > > > > On Fri, Mar 18, 2005 at 01:43:11PM -0500, Jason McMullan wrote: > > > > > On Fri, 2005-03-18 at 10:06 -0600, Kumar Gala wrote: > > > > > > Can you build your patch for the lopec_defconfig and fix the > >errors > >> > > > associated with enabling altivec. > > > > > > > >> > > > Looks like you need to include asm/offset.h & asm/page.h in > >vector.S, > >> > > > however there is another build error after that. > > > > > > >> > > Thanks! That also found a linking bug, fixed in this patch.. > >Please > > > > > double check the call in 'AltiVecUnavalible' in head.S, and the > >re-load > > > > > of 'ctr' at the end of load_up_altivec, as I do not have an > >AltiVec > > > > > machine here. > > > > > >> > No dice: > > > > VFS: Mounted root (nfs filesystem) readonly. > > > > Freeing unused kernel memory: 100k init 4k prep > > > > floating point used in kernel (task=c03816b0, pc=c000d664) > >> > Doing some objdump'ing, that's the start of load_up_altivec. > >> > >> Hi Jason and Tom, > > > > >> Has there been any more progress on this patch? > > > >Sadly no.? We got to the point where it was reliably crashing on my > >LoPEC (7400), but no time to try and fix it.? The problem should show > >up > > on any classic PPC box.. > > Is it crashing on just avec code or everything? That's a good question. IIRC, I was using a userspace with an altivec-using setjmp/longjmp, so it could have been Altivec-specific. I don't have test kernels w/ the patch handy anymore to verify, sorry. -- Tom Rini http://gate.crashing.org/~trini/
Problem running Linux 2.6.11 on MPC8272ADS
Well, it seems to be a historic problem. Freescale BSP was originally ported
from u-boot-1.0.0 and linux-2.4.22. So the BCSR was freely chosen as
0xf800. Later, we updated them to u-boot-1.1.1 and linux-2.4.26, and make
the BCSR consistent to older version. However the sourceforge u-boot-1.1.1
support for MPC8272ADS was committed by Arabella guys, they chose BCSR mapping
to 0xf450. Kumar's MPC8272 support which is in 2.6.11 source was developed
using sourceforge u-boot-1.1.1 seemingly.
This might brought up a question that if we need a convention or something to
define the recommended memory mapping for PowerPC BSPs. As there are different
groups of people around the world developing BSPs for PowerPC platforms, and
often the communication between them is very limited.
For now using kernel and u-boot released from the same vendor is recommended.
Best Regards,
Leo
> -Original Message-
> From: linuxppc-embedded-bounces at ozlabs.org
> [mailto:linuxppc-embedded-bounces at ozlabs.org] On Behalf Of Walter L. Wimer
> III
> Sent: Thursday, March 31, 2005 12:00 AM
> To: Linux PPC Embedded list
> Subject: Re: Problem running Linux 2.6.11 on MPC8272ADS
>
>
> 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 0xf800. The "regular" u-boot-1.1.1 (from sf.net) maps the BCSR to
> > 0xf450 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) 0xf450)
> > >>>From "u-boot/include/configs/MPC8260ADS.h"
> > >>#define CFG_BCSR 0xF450
> > >>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 at timesys.com]
> > >>>Sent:Monday, March 28, 2005 6:07 PM
> > >>>To: Mike Rapoport
> > >>>Cc: linuxppc-embedded at 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
> > t
Overcommit (OOM) problem on embedded device (PPChameleon)
Hi Per,
> I think your main problem is that the stock 2.4.x kernel doesn't support
> ovecommit_memory type 2 (i believe)...
Doooh! You're so right!
I read the docs on overcommit_memory from 2.6 - stupid me!
> Look in mm/mmap.c and search for overcommit_memory, then do same
> in the sources for your redhat kernels.
I'll look into RH kernel to see if it isn't like you say :-)
> Perhaps there's a patch for it floating around somewhere? ;-)
Now, that would be really nice.
Though I have no idea of where to look!?
Thanks for clearing my mind!
BR,
Martin
>
>
>>= Original Message From Martin Egholm Nielsen >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" (0x), 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
>>...
>>
>>
>>Out of memory
>># #Yeh!
>>
>>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
>>#include
>>#define SIZE 100
>>
>>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 at ozlabs.org
>>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
>
>
>
Linux crashes during memory mapping
23a20 433031351500C0 XER: C015 00178054: 30304138 204c523a 20303330 3030304300A8 LR: 03C 00178064: 30205350 3a203030 30333030 303120520 SP: 00030001 R 00178074: 4547533a 20633031 35303030 30205452EGS: c015 TR 00178084: 41503a20 63303135 30306330 20202020AP: c01500c0 00178094: 4e6f7420 7461696e 7465640a 3c343e4dNot tainted.<4>M 001780a4: 53523a20 66646661 2045453aSR: fdfa EE: 001780b4: 20312050 523a2031 2046503a 2031204d 1 PR: 1 FP: 1 M 001780c4: 453a2031 2049522f 44523a20 31310a3cE: 1 IR/DR: 11.< 001780d4: 343e5441 534b203d 20633031 346634374>TASK = c014f47 001780e4: 305b305d 20277377 61707065 7227204c0[0] 'swapper' L 001780f4: 61737420 73797363 616c6c3a 2030200aast syscall: 0 . 00178104: 3c343e6c 61737420 6d617468 20303030<4>last math 000 00178114: 30303030 30206c61 73742061 6c7469760 last altiv 00178124: 65632030 30303030 3030300a 3c343e43ec .<4>C 00178134: 616c6c20 6261636b 74726163 653a2030all backtrace: 0 00178144: 30303030 30303420 0a3c343e 4f6f7073004 .<4>Oops 00178154: 3a206b65 726e656c 20616363 65737320: kernel access 00178164: 6f662062 61642061 7265612c 20736967of bad area, sig 00178174: 3a203131 0a3c343e 4e49503a 20433031: 11.<4>NIP: C01 00178184: 35303043 30205845 523a2043 30313530500C0 XER: C0150 00178194: 30413820 4c523a20 30303030 313033320A8 LR: 1032 001781a4: 2053503a 20433030 31333946 30205245 SP: C00139F0 RE 001781b4: 47533a20 63303135 30303030 20545241GS: c015 TRA 001781c4: 503a2063 30313530 30633020 2020204eP: c01500c0N 001781d4: 6f742074 61696e74 65640a3c 343e4d53ot tainted.<4>MS 001781e4: 523a2066 64666120 45453a20R: fdfa EE: 001781f4: 31205052 3a203120 46503a20 31204d451 PR: 1 FP: 1 ME 00178204: 3a203120 49522f44 523a2031 310a3c34: 1 IR/DR: 11.<4 00178214: 3e544153 4b203d20 63303134 66343730>TASK = c014f470 00178224: 5b305d20 27737727 204c6173 74207379[0] 'sw' Last sy 00178234: 7363616c 6c3a202d 31303732 33363535scall: -10723655 00178244: 3638200a 3c343e6c 61737420 6d61746868 .<4>last math 00178254: 20303030 30303030 30206c61 73742061 last a 00178264: 6c746976 65632030 30303030 3030300altivec . 00178274: 1.Is all this information sufficient to help you understand and pin point our mistake, Is there any thing other than the parameters which are passed to the kernel from the u-boot that I need to look into. 2. I have a query in the Linux source code. I would like to know why the value of "ioremap_base = 0xfe00UL;" in linux/arch/ppc/mm/init.c line 356 has been hard coded and how was this value determined? What is the impact of this value? Any pointers, ideas, comments would be of great help. i would be more than glad to provide you with any further information required to debug the problem. Thanks and best regards, Atit ** This email (including any attachments) is intended for the sole use of the intended recipient/s and may contain material that is CONFIDENTIAL AND PRIVATE COMPANY INFORMATION. Any review or reliance by others or copying or distribution or forwarding of any or all of the contents in this message is STRICTLY PROHIBITED. If you are not the intended recipient, please contact the sender by email and delete all copies; your cooperation in this regard is appreciated. ** -- next part -- An HTML attachment was scrubbed... URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050331/1a82639d/attachment.htm
Flat OF Device Tree for ppc32 [was: Platform bus/ppc sys model...]
On Thu, 2005-03-31 at 06:33, Jon Masters wrote: > Kumar Gala wrote: > > |> My intention was to give a device tree structure to the kernel at boot > |> time via a (pseudo?) pointer in bd_info or similar. > This got resurrected recently. Hi! > | 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? > > Yes, but I've been tied up with worky and magazine stuff again. If > someone wants to work with me then this might actually happen. Hi Jon, I'm here and actively(!) working on it now. Here is the very rough plan as Kumar and I have discussed it. Please feel free to comment on it or offer suggestions. Ben has suggested that I start with the "second step" below. I'd like to do a round of cleanup first. So far, I have taken the first step of isolating the references to the global __res[] variable into one file and replacing all references to the data in the bd_t structure with a thin, shim layer of function calls that are nominally into an OF-like interface. I have done this for all the 85xx and 83xx boards in my development tree, and am working on the others now. This step effectively isolates the __res[] references to one file where a well defined interface can be created to pose as an OF Device Tree layer (briefly). As a follow-up second step, I plan on introducing essentially the same code currently in ppc64 to handle the flat device tree and provide an interface to that data in exactly the same manner as the ppc64 currently has. I understand the desire to have the flat-tree handling be "outside the kernel". As a third step, the shim layer will be rewritten/augmented to use the actual OF device tree data where it currently fronts for the bd_t data. Finally, as time permits and maintainers allow (read: prod), the other (not 85xx, not 83xx) boards can have their setup code converted to use the "real" OF device tree function calls. When all of that is done, the shim layer can be removed, as needed. Oh, yeah. Um, also on my plate will be to construct the original flat-tree blob in U-Boot to be handed to the kernel. (I'll start with 85xx and 83xx, naturlich.) We have not yet decided on the layout of that tree to determine where all the attributes and devices really belong. I will also discuss with Wolfgang and crew how to generate that tree over in U-Boot land. Right? Thanks, jdl
Problem running Linux 2.6.11 on MPC8272ADS
On Thu, 2005-03-31 at 02:22, Li Yang-r58472 wrote: > Good point. > There is also IMMR need to be passed from bootloader to kernel. We > can make more use of the u-boot bd_info mechanism. But it binds ppc > linux to u-boot boot loader. I don't know if we should make it a > porting convention. Hi guys, So, just for the record here, Kumar and I are moving the ppc32 line away from bd_t towards an OpenFirmware flattened device tree. That data will still have a place for the IMMR to be passed. Under another Subject:, I'll describe a brief outline of The Plan So Far so people can take shots at it. :-) > Best Regards, > Leo Thanks, jdl
440EP FPU patch
On Thu, Mar 31, 2005 at 09:26:18AM -0700, Wade Farnsworth wrote: > On Fri, 2005-03-18 at 12:30, Tom Rini wrote: > > On Fri, Mar 18, 2005 at 01:43:11PM -0500, Jason McMullan wrote: > > > On Fri, 2005-03-18 at 10:06 -0600, Kumar Gala wrote: > > > > Can you build your patch for the lopec_defconfig and fix the errors > > > > associated with enabling altivec. > > > > > > > > Looks like you need to include asm/offset.h & asm/page.h in vector.S, > > > > however there is another build error after that. > > > > > > Thanks! That also found a linking bug, fixed in this patch.. Please > > > double check the call in 'AltiVecUnavalible' in head.S, and the re-load > > > of 'ctr' at the end of load_up_altivec, as I do not have an AltiVec > > > machine here. > > > > No dice: > > VFS: Mounted root (nfs filesystem) readonly. > > Freeing unused kernel memory: 100k init 4k prep > > floating point used in kernel (task=c03816b0, pc=c000d664) > > Doing some objdump'ing, that's the start of load_up_altivec. > > Hi Jason and Tom, > > Has there been any more progress on this patch? Sadly no. We got to the point where it was reliably crashing on my LoPEC (7400), but no time to try and fix it. The problem should show up on any classic PPC box.. -- Tom Rini http://gate.crashing.org/~trini/
440EP FPU patch
On Fri, 2005-03-18 at 12:30, Tom Rini wrote: > On Fri, Mar 18, 2005 at 01:43:11PM -0500, Jason McMullan wrote: > > On Fri, 2005-03-18 at 10:06 -0600, Kumar Gala wrote: > > > Can you build your patch for the lopec_defconfig and fix the errors > > > associated with enabling altivec. > > > > > > Looks like you need to include asm/offset.h & asm/page.h in vector.S, > > > however there is another build error after that. > > > > Thanks! That also found a linking bug, fixed in this patch.. Please > > double check the call in 'AltiVecUnavalible' in head.S, and the re-load > > of 'ctr' at the end of load_up_altivec, as I do not have an AltiVec > > machine here. > > No dice: > VFS: Mounted root (nfs filesystem) readonly. > Freeing unused kernel memory: 100k init 4k prep > floating point used in kernel (task=c03816b0, pc=c000d664) > Doing some objdump'ing, that's the start of load_up_altivec. Hi Jason and Tom, Has there been any more progress on this patch? Thanks, Wade Farnsworth
Problem in Viewml why doing make
Hi, I downloaded the viewml0.23 from site and configured it with microwindows0.90 and FLNX0.14(FLTK1.0.7). When i gave the command make all i received the following messages. Can anyone help me in solving the problem in viewml 0.23 as early as possible. make[1]: Entering directory `/root/viewml/src' if [ ! -s .build_depends ]; then make -f build_depends.mk force-depends; fi make[2]: Entering directory `/root/viewml/src' Generating dependancies for /root/viewml/src... g++ -M -L/usr/include -INONE/include -I. -I../kdecore -I../kimgio -I../kdeui -I../jscript -I/root/flnx-0.17 -I/root/flnx-0.17/FL -I./fltk -I/root/microwindows-0.90/include -I/usr/include/microwin -I/include -I/include/par -g --permissive -DNANOX -D_NANOX -I/usr/X11R6/include `/usr/local/bin/libwww-config --cflags` html.cpp htmlchain.cpp htmlclue.cpp htmldata.cpp htmlfont.cpp htmliter.cpp htmltable.cpp htmltoken.cpp jscript.cpp htmlview.cpp htmlframe.cpp htmlobj.cpp debug.cpp htmlform.cpp main.cpp http.cpp http_.cpp ../kdecore/kurl.cpp ../kdeui/kcursor.cpp fltk/qtimer.cpp fltk/qobject.cpp fltk/qpainter.cpp fltk/qdrawutil.cpp fltk/qfont.cpp fltk/qrect.cpp fltk/qregexp.cpp fltk/qstring.cpp fltk/kcharsets.cpp fltk/qcolor.cpp fltk/qpixmap.cpp fltk/qfontinfo.cpp fltk/qwidget.cpp fltk/history.cpp fltk/qscrollbar.cpp fltk/nxslider.cpp fltk/nxscrollbar.cpp fltk/nxscroll.cpp >> .build_depends make[2]: Leaving directory `/root/viewml/src' make[1]: Leaving directory `/root/viewml/src' make[1]: Entering directory `/root/viewml/src' g++ -L/usr/include -INONE/include -I. -I../kdecore -I../kimgio -I../kdeui -I../jscript -I/root/flnx-0.17 -I/root/flnx-0.17/FL -I./fltk -I/root/microwindows-0.90/include -I/usr/include/microwin -I/include -I/include/par -g --permissive -DNANOX -D_NANOX -I/usr/X11R6/include `/usr/local/bin/libwww-config --cflags` -I.. -c -o html.o html.cpp In file included from /usr/include/c++/3.3.3/backward/algo.h:59, from fltk/qstring.h:4, from ../kdecore/kurl.h:31, from html.cpp:24: /usr/include/c++/3.3.3/backward/backward_warning.h:32:2: warning: #warning This file includes at least one deprecated or antiquated header. Please consider using one of the 32 headers found in section 17.4.1.2 of the C++ standard. Examples include substituting the header for the header for C++ includes, or instead of the deprecated header . To disable this warning use -Wno-deprecated. In file included from /usr/include/c++/3.3.3/bits/locale_facets.tcc:41, from /usr/include/c++/3.3.3/locale:47, from /usr/include/c++/3.3.3/bits/ostream.tcc:37, from /usr/include/c++/3.3.3/ostream:535, from /usr/include/c++/3.3.3/iostream:45, from /usr/include/c++/3.3.3/backward/iostream.h:32, from /usr/include/c++/3.3.3/backward/iterator.h:33, from /usr/include/c++/3.3.3/backward/algobase.h:60, from /usr/include/c++/3.3.3/backward/algo.h:60, from fltk/qstring.h:4, from ../kdecore/kurl.h:31, from html.cpp:24: /usr/include/c++/3.3.3/cmath:107: error: `acosf' not declared /usr/include/c++/3.3.3/cmath:110: error: `asinf' not declared /usr/include/c++/3.3.3/cmath:113: error: `atanf' not declared /usr/include/c++/3.3.3/cmath:116: error: `atan2f' not declared /usr/include/c++/3.3.3/cmath:119: error: `ceilf' not declared /usr/include/c++/3.3.3/cmath:122: error: `coshf' not declared /usr/include/c++/3.3.3/cmath:125: error: `expf' not declared /usr/include/c++/3.3.3/cmath:128: error: `floorf' not declared /usr/include/c++/3.3.3/cmath:131: error: `fmodf' not declared /usr/include/c++/3.3.3/cmath:134: error: `frexpf' not declared /usr/include/c++/3.3.3/cmath:137: error: `ldexpf' not declared /usr/include/c++/3.3.3/cmath:140: error: `logf' not declared /usr/include/c++/3.3.3/cmath:143: error: `log10f' not declared /usr/include/c++/3.3.3/cmath:146: error: `modff' not declared /usr/include/c++/3.3.3/cmath:149: error: `powf' not declared /usr/include/c++/3.3.3/cmath:152: error: `sinhf' not declared /usr/include/c++/3.3.3/cmath:155: error: `tanf' not declared /usr/include/c++/3.3.3/cmath:158: error: `tanhf' not declared /usr/include/c++/3.3.3/cmath: In function `float std::acos(float)': /usr/include/c++/3.3.3/cmath:184: error: `acosf' undeclared in namespace ` __gnu_cxx::__c99_binding' /usr/include/c++/3.3.3/cmath: At global scope: /usr/include/c++/3.3.3/cmath:190: error: `acos' not declared /usr/include/c++/3.3.3/cmath: In function `long double std::acos(long double)': /usr/include/c++/3.3.3/cmath:194: error: `::acosl' undeclared (first use here) /usr/include/c++/3.3.3/cmath: At global scope: /usr/include/c++/3.3.3/cmath:200: error: `asin' not declared /usr/include/c++/3.3.3/cmath: In function `float std::asin(float)': /usr/include/c++/3.3.3/cmath:204: error: `asinf' undeclared
Overcommit (OOM) problem on embedded device (PPChameleon)
Hi Per,
> I think your main problem is that the stock 2.4.x kernel doesn't support
> ovecommit_memory type 2 (i believe)...
Doooh! You're so right!
I read the docs on overcommit_memory from 2.6 - stupid me!
> Look in mm/mmap.c and search for overcommit_memory, then do same
> in the sources for your redhat kernels.
I'll look into RH kernel to see if it isn't like you say :-)
> Perhaps there's a patch for it floating around somewhere? ;-)
Now, that would be really nice.
Though I have no idea of where to look!?
Thanks for clearing my mind!
BR,
Martin
>
>
>>= Original Message From Martin Egholm Nielsen >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" (0x), 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
>>...
>>
>>
>>Out of memory
>># #Yeh!
>>
>>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
>>#include
>>#define SIZE 100
>>
>>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 at ozlabs.org
>>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
>
>
>
Overcommit (OOM) problem on embedded device (PPChameleon)
> > Look in mm/mmap.c and search for overcommit_memory, then do same
> > in the sources for your redhat kernels.
> I'll look into RH kernel to see if it isn't like you say :-)
>
> > Perhaps there's a patch for it floating around somewhere? ;-)
> Now, that would be really nice.
> Though I have no idea of where to look!?
>
Here is what I do. Patch is against BK linuxppc-2.4 version 1.1285
(2.4.28-pre3) but might work.
Burns 5% of the RAM but alternatives all seem worse and I never
have much luck trying to convince my colleagues that
dynamic allocation has no place in an embedded system.
If you find out why RH works it would be interesting ... perhaps
there is a better way.
David
#
# mm/mmap.c
# Add pessimistic overcommit mode similar to 2.6 mode 2.
# This allows malloc aka sbrk() to actually fail before
# process is killed.
# Overloaded sysctl_overcommit_memory to be both enable
# and ratio to avoid making a new sysctl.
#
diff -Nru a/mm/mmap.c b/mm/mmap.c
--- a/mm/mmap.c 2005-03-30 07:15:13 -08:00
+++ b/mm/mmap.c 2005-03-30 07:15:13 -08:00
@@ -45,9 +45,13 @@
__S000, __S001, __S010, __S011, __S100, __S101, __S110, __S111
};
-int sysctl_overcommit_memory;
+int sysctl_overcommit_memory = 98;
+
int max_map_count = DEFAULT_MAX_MAP_COUNT;
+extern unsigned long totalram_pages;
+extern unsigned long totalhigh_pages;
+
/* Check that a process has enough memory to allocate a
* new virtual mapping.
*/
@@ -66,7 +70,7 @@
unsigned long free;
/* Sometimes we want to use more memory than we have. */
- if (sysctl_overcommit_memory)
+ if (sysctl_overcommit_memory == 1)
return 1;
/* The page cache contains buffer pages these days.. */
@@ -91,7 +95,20 @@
free += (dentry_stat.nr_unused * sizeof(struct dentry)) >>
PAGE_SHIFT;
free += (inodes_stat.nr_unused * sizeof(struct inode)) >>
PAGE_SHIFT;
+ /*
+* Leave the last 3% for root
+*/
+ if (current->euid)
+ free -= free / 32;
+
+ /* Strict mode do not allocate last bit of memory */
+ if (sysctl_overcommit_memory) {
+ pages += (totalram_pages - totalhigh_pages)
+ * (100 - sysctl_overcommit_memory) / 100;
+ }
+
return free > pages;
+
}
/* Remove one vm structure from the inode's i_mapping address space. */
Linux crashes during memory mapping
> I do not have any problem with the functioning of U-Boot but Linux crashes after > printing "Uncompressing Kernel ... OK" and then it seems that nothing is happening. Do you have the SYPCR(serial watch dog timer) disabled? > 3. The memory map of the VPN Board (MY BOARD) is as folllows: > = > Memory RegionSize Address Range > == > SDRAM32MByte _ -- 01FF_ > Flash32MByte FF00_ -- _ Have you done a full test to make sure your RAM is correctly mapped? > This is what the console log buffer has shown: > = > md 0x00177e34 > > 00177e34: 3c363e6d 73746172 743d303c 363e6d73 <6>mstart=0<6>ms > 00177e44: 697a653d 303c363e 66737461 72743d30 ize=0<6>fstart=0 > 00177e54: 3c363e66 73697a65 3d303c36 3e696d6d <6>fsize=0<6>imm > 00177e64: 723d303c 363e626f 74666c61 673d303c r=0<6>botflag=0< > 00177e74: 363e6970 6164643d 303c363e 65616464 6>ipadd=0<6>eadd > 00177e84: 3d633031 35303032 383c363e 65737065 =c0150028<6>espe > 00177e94: 643d303c 363e696e 6974663d 303c363e d=0<6>initf=0<6> > 00177ea4: 62757366 3d303c36 3e63706d 663d303c busf=0<6>cpmf=0< > 00177eb4: 363e6272 67663d30 3c363e73 6363663d 6>brgf=0<6>sccf= > 00177ec4: 303c363e 76636f3d 303c363e 62617564 0<6>vco=0<6>baud > 00177ed4: 3d304f6f 70733a20 6b65726e 656c2061=0Oops: kernel a These values do not look correct. Everything is zero.
Problem running Linux 2.6.11 on MPC8272ADS
On Thu, Mar 31, 2005 at 04:22:26PM +0800, Li Yang-r58472 wrote: > Good point. > There is also IMMR need to be passed from bootloader to kernel. We > can make more use of the u-boot bd_info mechanism. But it binds ppc > linux to u-boot boot loader. I don't know if we should make it a > porting convention. Well, immr is _already_ part of bd_t passed from U-Boot! I was surprised that none of board ports (some of which are made for U-Boot only) use this. In 8248 based board port I'm working on right now, I already defined CPM_MAP_ADDR as follows: #define CPM_MAP_ADDR(((bd_t*)__res)->bi_immr_base) -- Eugene
