* Re: [PATCH] balance ioremap/iounmap in {sycamore, walnut}_setup_arch()
From: Roel Kluin @ 2007-11-09 12:32 UTC (permalink / raw)
To: Valentine Barshak; +Cc: linuxppc-dev
In-Reply-To: <47333EDA.4080907@ru.mvista.com>
Valentine Barshak wrote:
> Roel Kluin wrote:
>> I guess it should be done after the last usage of kb_data or fpga_status?
>
> I think no iounmap(kb_data) needed. Looks like the pointer kn_cs (kb_cs
> = kb_data + 1) is used by the serio driver
> (drivers/input/serio/i8042-ppcio.h).
> Please note that we just ioremap and assign pointers here, not actually
> reading the registers.
> Also, looks like you unmap the fpga registers too early.
> Thanks,
> Valentine.
Thanks for your pointers. I'm new, so I'm not sure how this should be done. I
have removed the iounmap(kb_data), and moved the iounmap(fpga_status) lower.
possibly the latter could be done before the sycamore_rtc_base assignment?
--
Balance ioremap/iounmap
Signed-off-by: Roel Kluin <12o3l@tiscali.nl>
---
diff --git a/arch/ppc/platforms/4xx/sycamore.c b/arch/ppc/platforms/4xx/sycamore.c
index 8689f3e..6ce4815 100644
--- a/arch/ppc/platforms/4xx/sycamore.c
+++ b/arch/ppc/platforms/4xx/sycamore.c
@@ -132,6 +132,7 @@ sycamore_setup_arch(void)
sycamore_rtc_base = (void *) SYCAMORE_RTC_VADDR;
TODC_INIT(TODC_TYPE_DS1743, sycamore_rtc_base, sycamore_rtc_base,
sycamore_rtc_base, 8);
+ iounmap(fpga_status);
/* Identify the system */
printk(KERN_INFO "IBM Sycamore (IBM405GPr) Platform\n");
^ permalink raw reply related
* Re: Bootloader & Flash
From: schardt @ 2007-11-09 12:07 UTC (permalink / raw)
To: MingLiu; +Cc: linuxppc-embedded
In-Reply-To: <BAY138-W14EEE9667CD669878D3BD0B28A0@phx.gbl>
Hi again,
i've learned a little bit :)
- I have download the zImage.elf via the EDK flash loader
- The flash loader creates a bootloader, this is also running on start up=
:)
But ... It stops with an error-message after a few seconds:
EDK Bootloader:
Bootloader: Processed (0x)000000b2 S-recordsERROR: SREC line is corrupted=
What now ?
Georg
MingLiu wrote:
> Dear Georg,
> I guess you were talking about the booting process of the system, both =
HW and the SW, from the flash memory. This process should be like this:
>
> 1. Store your HW bitstream and Linux kernel in flash memories. If neede=
d, perhaps you want another bootloader program, such as U-boot also insid=
e.=20
>
> 2. In your HW bitstream, you need one bootloader which helps you to loa=
d the software and execute it in DDR-ram. EDK helps you to generate such =
a bootloader when you design.=20
>
> 3. Durong Power on, HW bitstream (with an EDK bootloader included) will=
be loaded into FPGA and configure the FPGA, then the EDK bootloader will=
load your Linux kernel into DDR-Ram and execute it there. Thus your linu=
x could run.=20
>
> This is a normal process. If you want to execute the program in flash d=
irectly, that's another story. Also you should know, for the booting proc=
ess, MTD driver is not necessary. The driver is only used when you want t=
o access flash memories when you booted your Linux kernel.
>
> Clear or not? :)
>
> Best Regards
> Ming
>
> ----------------------------------------> Date: Wed, 7 Nov 2007 13:00:3=
5 +0100> From: g.schardt@fz-juelich.de> To: Linuxppc-embedded@ozlabs.org>=
Subject: Bootloader & Flash>> Hi,>> i use the AVnet Xilinx4 FX12 Minimod=
ule and until now, i use system-ace> to configure the fpga and boot the l=
inux kernel.> But now, i want to boot from the on board flash memory and =
have no idea> where to start.>> I think i have to:> - save the fpga confi=
guration in the fpga-prom> - use/program some kind of bootloader store in=
fpga block ram to jump to> the flash-adress where the executable linux k=
ernel resist> - use the mtd-device driver to mount root fs on the same fl=
ash some> address later>> Is this the right way ?>>> Regards> Georg>>>>>>=
> -----------------------------------------------------------------------=
------------------> -----------------------------------------------------=
------------------------------------> Forschungszentrum J=C3=BClich GmbH>=
52425 J=C3=BClich>> Sitz der Gesellschaft: J=C3=BClich> Eingetragen im H=
andelsregister des Amtsgerichts D=C3=BCren Nr. HR B 3498> Vorsitzende des=
Aufsichtsrats: MinDirig'in B=C3=A4rbel Brumme-Bothe> Gesch=C3=A4ftsf=C3=BC=
hrung: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv.>=
Vorsitzender)> ---------------------------------------------------------=
--------------------------------> ---------------------------------------=
--------------------------------------------------> _____________________=
__________________________> Linuxppc-embedded mailing list> Linuxppc-embe=
dded@ozlabs.org> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
> _________________________________________________________________
> MSN =E4=B8=AD=E6=96=87=E7=BD=91=EF=BC=8C=E6=9C=80=E6=96=B0=E6=97=B6=E5=B0=
=9A=E7=94=9F=E6=B4=BB=E8=B5=84=E8=AE=AF=EF=BC=8C=E7=99=BD=E9=A2=86=E8=81=9A=
=E9=9B=86=E9=97=A8=E6=88=B7=E3=80=82
> http://cn.msn.com
=0A=0A-------------------------------------------------------------------------=
----------------=0A-----------------------------------------------------------=
------------------------------=0AForschungszentrum J=C3=BClich GmbH=0A52425 J=C3=BClich=
=0A=0ASitz der Gesellschaft: J=C3=BClich=0AEingetragen im Handelsregister des Amtsgeri=
chts D=C3=BCren Nr. HR B 3498=0AVorsitzende des Aufsichtsrats: MinDirig'in B=C3=A4rbel=
Brumme-Bothe=0AGesch=C3=A4ftsf=C3=BChrung: Prof. Dr. Achim Bachem (Vorsitzender), Dr.=
Ulrich Krafft (stellv. =0AVorsitzender)=0A-------------------------------------=
----------------------------------------------------=0A-----------------------=
------------------------------------------------------------------=0A
^ permalink raw reply
* Re: [PATCH] using mii-bitbang on different processor ports - update the booting-without-of.txt-file
From: Sergej Stepanov @ 2007-11-09 11:38 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, jgarzik, netdev
In-Reply-To: <47336F9D.8060405@freescale.com>
Am Donnerstag, den 08.11.2007, 14:20 -0600 schrieb Scott Wood:
> Sergej Stepanov wrote:
> > If both mdio and mdc controlling pins are on the same processor port,
> > one resource should be used.
> > Otherwise, two resources are used: the 1-st - mdio, the 2-nd - mdc.
>
> How about:
> The first reg resource is the I/O port register block on which MDIO
> resides. The second reg resource is the I/O port register block on
> which MDC resides. If there is only one reg resource, it is used for
> both MDIO and MDC.
>
Ok.
> We also need to change the reference to port C in fsl,mdio-pin and
> fsl,mdc-pin.
Do you mean this:
Currently defined compatibles:
fsl,pq1-fec-mdio (reg is same as first resource of FEC device)
-> fsl,cpm2-mdio-bitbang (reg is port C registers)
Properties for fsl,cpm2-mdio-bitbang:
-> fsl,mdio-pin : pin of port C controlling mdio data
-> fsl,mdc-pin : pin of port C controlling mdio clock
Right. But i thought it would be related to the example,
and than the reader gets the short comment about I/O ports.
Or the other variant would be:
--------------------
iv) MDIO
Currently defined compatibles:
fsl,pq1-fec-mdio (reg is same as first resource of FEC device)
fsl,cpm2-mdio-bitbang (reg is the I/O port register block(s))
Properties for fsl,cpm2-mdio-bitbang:
The first reg resource is the I/O port register block on which MDIO
resides. The second reg resource is the I/O port register block on
which MDC resides. If there is only one reg resource, it is used for
both MDIO and MDC.
fsl,mdio-pin : pin of chosen port for controlling mdio data
fsl,mdc-pin : pin of chosen port for controlling mdio clock
Example:
mdio@10d40 {
device_type = "mdio";
compatible = "fsl,mpc8272ads-mdio-bitbang",
"fsl,mpc8272-mdio-bitbang",
"fsl,cpm2-mdio-bitbang";
reg = <10d40 14>;
#address-cells = <1>;
#size-cells = <0>;
fsl,mdio-pin = <12>;
fsl,mdc-pin = <13>;
};
-----------------
Regards
Sergej.
^ permalink raw reply
* Please pull from 'for-2.6.24' branch
From: Kumar Gala @ 2007-11-09 9:59 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
Please pull from 'for-2.6.24' branch of
master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git for-2.6.24
to receive the following updates:
arch/powerpc/Makefile | 3 +++
arch/powerpc/sysdev/cpm_common.c | 4 +---
include/asm-powerpc/tlbflush.h | 4 ++--
3 files changed, 6 insertions(+), 5 deletions(-)
Kumar Gala (2):
[POWERPC] Add -mno-spe for ARCH=powerpc builds
[POWERPC] Fix oops related to 4xx flush_tlb_page modification
Scott Wood (1):
[POWERPC] cpm: Fix a couple minor issues in cpm_common.c.
^ permalink raw reply
* [PATCH] [POWERPC] Fix oops related to 4xx flush_tlb_page modification
From: Kumar Gala @ 2007-11-09 9:58 UTC (permalink / raw)
To: linuxppc-dev
kmap_atomic calls flush_tlb_page with a NULL VMA and thus we end
up dereferencing a NULL pointer to try and get the context.id.
If the VMA is null use the global pid value of 0.
---
include/asm-powerpc/tlbflush.h | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/asm-powerpc/tlbflush.h b/include/asm-powerpc/tlbflush.h
index e7b4c0d..5c91081 100644
--- a/include/asm-powerpc/tlbflush.h
+++ b/include/asm-powerpc/tlbflush.h
@@ -44,13 +44,13 @@ static inline void flush_tlb_mm(struct mm_struct *mm)
static inline void flush_tlb_page(struct vm_area_struct *vma,
unsigned long vmaddr)
{
- _tlbie(vmaddr, vma->vm_mm->context.id);
+ _tlbie(vmaddr, vma ? vma->vm_mm->context.id : 0);
}
static inline void flush_tlb_page_nohash(struct vm_area_struct *vma,
unsigned long vmaddr)
{
- _tlbie(vmaddr, vma->vm_mm->context.id);
+ _tlbie(vmaddr, vma ? vma->vm_mm->context.id : 0);
}
static inline void flush_tlb_range(struct vm_area_struct *vma,
--
1.5.3.3
^ permalink raw reply related
* Re: [PATCH] Fix buglets in mpc5200 FEC code that are corrupting memory.
From: Domen Puncer @ 2007-11-09 9:12 UTC (permalink / raw)
To: Jon Smirl; +Cc: PowerPC dev list, netdev
In-Reply-To: <9e4733910711082131v70c4b7bm2b00445b7e62c33f@mail.gmail.com>
On 09/11/07 00:31 -0500, Jon Smirl wrote:
> This is the reason I couldn't get user space started or connect to my
> nfs server. Patch is against current linus git.
>
> mpc5200 fec driver is corrupting memory. This patch fixes two bugs
> where the wrong skb buffer was being referenced.
>
> Signed-off-by: Jon Smirl <jonsmirl@gmail.com>
Acked-by: Domen Puncer <domen.puncer@telargo.com>
I can't test it at the moment, but the patch is obviously correct,
mapped buffer should be the _same_ as submitted.
>
> ---
>
> drivers/net/fec_mpc52xx.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
>
> diff --git a/drivers/net/fec_mpc52xx.c b/drivers/net/fec_mpc52xx.c
> index a8a0ee2..ddfcc0b 100644
> --- a/drivers/net/fec_mpc52xx.c
> +++ b/drivers/net/fec_mpc52xx.c
> @@ -422,7 +422,7 @@ static irqreturn_t mpc52xx_fec_rx_interrupt(int
> irq, void *dev_id)
>
> rskb = bcom_retrieve_buffer(priv->rx_dmatsk, &status,
> (struct bcom_bd **)&bd);
> - dma_unmap_single(&dev->dev, bd->skb_pa, skb->len, DMA_FROM_DEVICE);
> + dma_unmap_single(&dev->dev, bd->skb_pa, rskb->len, DMA_FROM_DEVICE);
>
> /* Test for errors in received frame */
> if (status & BCOM_FEC_RX_BD_ERRORS) {
> @@ -467,7 +467,7 @@ static irqreturn_t mpc52xx_fec_rx_interrupt(int
> irq, void *dev_id)
> bcom_prepare_next_buffer(priv->rx_dmatsk);
>
> bd->status = FEC_RX_BUFFER_SIZE;
> - bd->skb_pa = dma_map_single(&dev->dev, rskb->data,
> + bd->skb_pa = dma_map_single(&dev->dev, skb->data,
> FEC_RX_BUFFER_SIZE, DMA_FROM_DEVICE);
>
> bcom_submit_next_buffer(priv->rx_dmatsk, skb);
>
>
> --
> Jon Smirl
> jonsmirl@gmail.com
--
Domen Puncer | Research & Development
.............................................................................................
Telargo d.o.o. | Zagrebška cesta 20 | 2000 Maribor | Slovenia
.............................................................................................
www.telargo.com
^ permalink raw reply
* Re: Kernel locks up after calling kernel_execve()
From: Benjamin Herrenschmidt @ 2007-11-09 7:50 UTC (permalink / raw)
To: Gerhard Pircher; +Cc: linuxppc-dev
In-Reply-To: <20071109074155.266120@gmx.net>
> I tried to use /bin/sh as init program and was able to enter a command,
> but then the machine locked up, too.
> Could that be a problem with a CPU sleeping/idle code?
That's possibly an issue, try disabling power save if any for that CPU
type. If it worked and broke, you may have to bisect tho.
Ben.
^ permalink raw reply
* Re: Kernel locks up after calling kernel_execve()
From: Gerhard Pircher @ 2007-11-09 7:41 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
In-Reply-To: <1194564017.6561.21.camel@pasglop>
-------- Original-Nachricht --------
> Datum: Fri, 09 Nov 2007 10:20:17 +1100
> Von: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> An: Gerhard Pircher <gerhard_pircher@gmx.net>
> CC: linuxppc-dev@ozlabs.org
> Betreff: Re: Kernel locks up after calling kernel_execve()
>
> On Thu, 2007-11-08 at 22:47 +0100, Gerhard Pircher wrote:
> > Hi,
> >
> > I tested my patches for the AmigaOne platform with the lastest
> > 2.6.24-rc2 kernel snapshot. The kernel runs through all initcalls, but
> > locks up completely after calling INIT (/sbin/init) by kernel_execve().
> > Thus I couldn't capture any kernel oops or panic output. Also the magic
> > sysrq key doesn't work. Enabling debug code for soft lockups and
> > spinlock debugging didn't reveal any information.
> > I'm not sure, but I think it is the same problem I had with all kernels
> > >= 2.6.17. All of these kernels lock up shortly before or right at
> > calling the init program (resp. as soon as the kernel forks some kernel
> > theads).
> > Any suggestions on how to track down this problem?
>
> You don't have a HW debugger or anything like that ?
>
> Ben.
Unfortunately, no. A BDI2000 is too costly for me.
I tried to use /bin/sh as init program and was able to enter a command,
but then the machine locked up, too.
Could that be a problem with a CPU sleeping/idle code?
Gerhard
--
Psssst! Schon vom neuen GMX MultiMessenger gehört?
Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger
^ permalink raw reply
* help linux for linux2.6
From: vincent.liu @ 2007-11-09 6:39 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <200711091434079212507@bmrtech.com>
Hi
These days I am working on a MPC8270 based board with linux 2.6.10 kernel.
When I use the default kernel and load the uImage to the target board.
The kernel hangs after uncompressing kernel image ... ok .
I am freshman in the embedded linux area,So I do not know how to go on this project.
>From internet , I searched many articles,and no gain.
Please help me .
Thanks a lot.
--------------
vincent.liu
2007-11-09
^ permalink raw reply
* [PATCH] ibm_newemac: Add ET1011c PHY support
From: Stefan Roese @ 2007-11-09 6:07 UTC (permalink / raw)
To: linuxppc-dev
This adds support for the Agere ET1011c PHY as found on the AMCC Taishan
board.
Signed-off-by: Stefan Roese <sr@denx.de>
---
drivers/net/ibm_newemac/phy.c | 33 +++++++++++++++++++++++++++++++++
1 files changed, 33 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ibm_newemac/phy.c b/drivers/net/ibm_newemac/phy.c
index 1404457..4270a66 100644
--- a/drivers/net/ibm_newemac/phy.c
+++ b/drivers/net/ibm_newemac/phy.c
@@ -314,6 +314,38 @@ static struct mii_phy_def bcm5248_phy_def = {
.ops = &generic_phy_ops
};
+static int et1011c_init(struct mii_phy *phy)
+{
+ u16 reg_short;
+
+ reg_short = (u16)(phy_read(phy, 0x16));
+ reg_short &= ~(0x7);
+ reg_short |= 0x6; /* RGMII Trace Delay*/
+ phy_write(phy, 0x16, reg_short);
+
+ reg_short = (u16)(phy_read(phy, 0x17));
+ reg_short &= ~(0x40);
+ phy_write(phy, 0x17, reg_short);
+
+ phy_write(phy, 0x1c, 0x74f0);
+ return 0;
+}
+
+static struct mii_phy_ops et1011c_phy_ops = {
+ .init = et1011c_init,
+ .setup_aneg = genmii_setup_aneg,
+ .setup_forced = genmii_setup_forced,
+ .poll_link = genmii_poll_link,
+ .read_link = genmii_read_link
+};
+
+static struct mii_phy_def et1011c_phy_def = {
+ .phy_id = 0x0282f000,
+ .phy_id_mask = 0x0fffff00,
+ .name = "ET1011C Gigabit Ethernet",
+ .ops = &et1011c_phy_ops
+};
+
static int m88e1111_init(struct mii_phy *phy)
{
printk("%s: Marvell 88E1111 Ethernet\n", __FUNCTION__);
@@ -344,6 +376,7 @@ static struct mii_phy_def m88e1111_phy_def = {
};
static struct mii_phy_def *mii_phy_table[] = {
+ &et1011c_phy_def,
&cis8201_phy_def,
&bcm5248_phy_def,
&m88e1111_phy_def,
--
1.5.3.5.561.g140d
^ permalink raw reply related
* Re: [PATCH 2/6] ibm_newemac: Add ET1011c PHY support
From: Stefan Roese @ 2007-11-09 5:44 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
In-Reply-To: <1194555321.6561.4.camel@pasglop>
On Thursday 08 November 2007, Benjamin Herrenschmidt wrote:
> > DENX is pretty good about having Signed-off-by lines in their tree...
> > maybe you should add the original authors as well if it's there.
>
> I picked it up from an already patched tree. Stefan, can you provide me
> the proper SOB ?
Sure:
Signed-off-by: Stefan Roese <sr@denx.de>
Thanks.
Best regards,
Stefan
^ permalink raw reply
* [PATCH] Fix buglets in mpc5200 FEC code that are corrupting memory.
From: Jon Smirl @ 2007-11-09 5:31 UTC (permalink / raw)
To: PowerPC dev list, Domen Puncer, Grant Likely, netdev
This is the reason I couldn't get user space started or connect to my
nfs server. Patch is against current linus git.
mpc5200 fec driver is corrupting memory. This patch fixes two bugs
where the wrong skb buffer was being referenced.
Signed-off-by: Jon Smirl <jonsmirl@gmail.com>
---
drivers/net/fec_mpc52xx.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/fec_mpc52xx.c b/drivers/net/fec_mpc52xx.c
index a8a0ee2..ddfcc0b 100644
--- a/drivers/net/fec_mpc52xx.c
+++ b/drivers/net/fec_mpc52xx.c
@@ -422,7 +422,7 @@ static irqreturn_t mpc52xx_fec_rx_interrupt(int
irq, void *dev_id)
rskb = bcom_retrieve_buffer(priv->rx_dmatsk, &status,
(struct bcom_bd **)&bd);
- dma_unmap_single(&dev->dev, bd->skb_pa, skb->len, DMA_FROM_DEVICE);
+ dma_unmap_single(&dev->dev, bd->skb_pa, rskb->len, DMA_FROM_DEVICE);
/* Test for errors in received frame */
if (status & BCOM_FEC_RX_BD_ERRORS) {
@@ -467,7 +467,7 @@ static irqreturn_t mpc52xx_fec_rx_interrupt(int
irq, void *dev_id)
bcom_prepare_next_buffer(priv->rx_dmatsk);
bd->status = FEC_RX_BUFFER_SIZE;
- bd->skb_pa = dma_map_single(&dev->dev, rskb->data,
+ bd->skb_pa = dma_map_single(&dev->dev, skb->data,
FEC_RX_BUFFER_SIZE, DMA_FROM_DEVICE);
bcom_submit_next_buffer(priv->rx_dmatsk, skb);
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply related
* Re: [PATCH] [POWERPC] Fix typo #ifdef -> #ifndef
From: Andrew Morton @ 2007-11-09 4:35 UTC (permalink / raw)
To: Jochen Friedrich; +Cc: jeff, netdev, linux-kernel, linuxppc-embedded
In-Reply-To: <472CC914.3030709@scram.de>
> On Sat, 03 Nov 2007 20:16:36 +0100 Jochen Friedrich <jochen@scram.de> wrote:
> Subject: [PATCH] [POWERPC] Fix typo #ifdef -> #ifndef
Please put the "powerpc" outside the []. Because things inside [] get
removed when the receiver applies the patch, but the subsystem
identification ("powerpc") is useful information which we want to carry
into the permanent git record. (Although Paul might add it anyway - some
git tree maintainers do).
> User-Agent: Mozilla-Thunderbird 2.0.0.6 (X11/20071009)
This seems to be setting a record for MUA vandalism. Leading spaces were
removed and various esoteric whitespace transformations were made. The
diffs were small so I fixed them by hand.
Please strangle your email client.
^ permalink raw reply
* Re: [PATCH 3/4] Use embedded libfdt in the bootwrapper
From: Jerry Van Baren @ 2007-11-09 0:52 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <473392A3.4010203@freescale.com>
Scott Wood wrote:
> David Gibson wrote:
>>> How hard would it be to get libfdt to dynamically allocate any extra space
>>> it needs? This is a regression from the current flat device tree code...
>> Uh.. it already does. Or rather, the shims in libfdt-wrapper.c do so,
>> when libfdt functions which can expand the tree report that they've
>> run out of room.
>
> Ah, good -- I was looking in libfdt itself, not the wrapper. Now if
> only we could get something similar into u-boot... maybe libfdt proper
> could accept an optional realloc() function pointer in fdt_init(), and
> eliminate the need for the caller to provide such a wrapper?
>
> -Scott
Hi Scott,
My concern from the u-boot side is that u-boot has to know exactly
*where* to put the expanded blob because it has to pass it to linux and
keep it out of linux' way so it doesn't get "stepped on." Linux has an
advantage in that it "owns" all of memory and can allocate and
deallocate whatever and wherever and it won't step on itself (hopefully).
I'm assuming your boot wedge has the advantage of being able to use
linux's malloc() and thus don't have to worry about coordinating with
linux on memory allocation.
With the current u-boot fdt command, you can resize the blob, and this
can be done in a script with all the (somewhat limited) capabilities of
the u-boot shell (an adaptation of hush).
In the u-boot world, we fixate on memory maps and putting things in
specific places. Maybe I'm making a problem where one doesn't exist,
but an arbitrary malloc() in u-boot (as opposed to linux's malloc) seems
like a Bad Thing[tm] because it is uncontrolled and may end up in a very
bad place when linux starts (e.g. the linux start up script expands
linux on top of the blob).
Best regards,
gvb
^ permalink raw reply
* Re: DTS Bytestrings Representation in /dts-v1/ files
From: David Gibson @ 2007-11-09 0:21 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
In-Reply-To: <E1IqCtu-0000ZE-Vi@jdl.com>
On Thu, Nov 08, 2007 at 01:18:50PM -0600, Jon Loeliger wrote:
>
> Folks,
>
> When the new DTS /dts-v1/ support is released Real Soon Now,
> it will support C-like literal constants. Hex values will be
> prefixed with 0x, binary with 0b, and bare numbers will be
> decimal unless they start with a leading 0.
>
> One outstanding question on which I'd like some feedback
> is the issue of bytestring value representation.
>
> Currently they look like this:
>
> stuff = [ 0b 31 22 de ea ad be ef ];
Or, equivalently, like this:
stuff = [0b3122deeaadbeef];
I think it's important to be aware of the more compact form when
considering whether to change the representation.
> One opinion is to have them continue to look like that
> and be in hex only.
>
> Another opinion is to allow the new, consistent C-style
> literals and expressions so that one could have:
>
> new_stuff = [ 0x31 49 '1' 23 17 ];
>
> Opinions?
>
> Thanks,
> jdl
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH] Use SLB size from the device tree
From: Olof Johansson @ 2007-11-09 0:16 UTC (permalink / raw)
To: Michael Neuling; +Cc: linuxppc-dev, paulus, Will Schmidt
In-Reply-To: <510.1194565218@neuling.org>
On Fri, Nov 09, 2007 at 10:40:18AM +1100, Michael Neuling wrote:
> Currently we hardwire the number of SLBs but the PAPR says we export an
> ibm,slb-size property to specify the number of SLB entries. This patch
> uses this property instead of assuming 64 always. If no property is
> found, we assume 64 entries as before.
>
> This soft patches the SLB handler, so it won't change performance at
> all.
>
> Signed-off-by: Michael Neuling <mikey@neuling.org>
Acked-by: Olof Johansson <olof@lixom.net>
I wonder if it isn't time soon to move all the mmu_.* globals to a
struct. That's a separate issue though.
-Olof
^ permalink raw reply
* Re: [PATCH] DTC: Polish up the DTS Version 1 implementation.
From: David Gibson @ 2007-11-09 0:13 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev, Jon Loeliger
In-Reply-To: <47331979.7030803@freescale.com>
On Thu, Nov 08, 2007 at 08:13:13AM -0600, Jon Loeliger wrote:
> David Gibson wrote:
> >
> > Yes, I know, but I don't think it's even worth having the unused
> > internal parameterization.
>
> OK. We can eliminate it then; no problem.
>
> >> I ran my "old versus new DTC" comparison script and found it. :-)
> >
> > Heh, we should fold that into the testsuite, too.
>
> I'll start by simply adding the script to the test directory then.
Ok.
> >> Because it wasn't working, as explained in the comment I added.
> >> Specifically, (1<<bits), with bits==64 overflowed and yielded
> >> the value 0.
> >
> > Ah...
> >
> > Well, I assumed (1ULL << 64) would equal 0, which is why the
> > comparison has the (-1) - I was expecting for bits == 64 it would end
> > up being against -1, i.e. 0xffffffffffffffff. This appears to work on
> > the systems I've been using.
>
> But not on an x86 system.
>
> > But I just remembered that (x << n) has undefined behaviour in C when
> > n >= word size.
>
> Exactly. In fact, I think x86 takes the shift value, bit-wise
> ANDs it with 63 internally, and then shifts left by that value.
>
> So I guess (1 << 64) is just returning garbage - I
>
> In fact, it is yielding 1 on an x86 machine.
>
> > suspect I didn't catch it because I've been building with -O0 for
> > gdb-ability, which might change the behaviour of corner cases like
> > that.
>
> Or works on a PPC machine? :-)
Actually I was working from home on an x86 machine when I wrote that,
so I think it must have been the -O0.
> > So I guess we need
> > else if ((errno == ERANGE)
> > || ((bits < 64) && (val >= (1ULL << bits))))
>
> Sounds good. I'll commit --amend that into the patch!
>
>
> >> And in the blue corner, touting consistent hex forms, ...
> >
> > And in the red, compact bytestring representations.
>
> > No, seriously, the inconsistency bothers me too. But so does the fact
> > that using 0x in the bytestring would double the minimum size for
> > representing bytestrings, somewhat changing the flavour of [] as well
> > (because spaces are no longer optional). I'm looking for a killer
> > argument one way or the other, but I haven't found it yet.
>
> But why does it even have to be hex numbers at all?
> I guess my point is that they could just be expressions.
> You could use 0x31 or 49 or '1' or 061, whichever made
> more sense in some application. You don't necessarily take
> a representational size hit.
But you do take a hit w.r.t. *minimum* representation size - there's
no form amongst all the possibilities here more compact than pure hex.
Especially since spaces are optional in the old form. The fact that
[ab cd 00] and [abcd00] are equivalent was a deliberate choice in the
original form.
The point of [] is for random binary data which is neither strings
(even with the odd strange character) nor sensibly organized into
32-bit (or larger) integers. Wanting something other than hex here is
much rarer than in the < > case.
You're seeing < > and [ ] as basically the same thing - a list of
values - with the only difference being the size of those values.
That's not wrong, but it's not the only way to look at it - and it's
not the way I was thinking of [ ] when I invented it. Your proposal
makes perfect sense while you think of [] as a list of values - but
not so much when it's thought of as a direct binary representation.
So I'm thinking perhaps we need two different things here: a "list of
values" representation, which can accomodate expressions and can also
have multiple sizes (because expressions which are evaluated to a
16-bit or 64-bit value could also be useful under the right
circumstances), and the [ ] "bytestring
literal" representation. Perhaps something like:
(32-bit values)
<0xdeadbeef (1+1)>
or <.32 0xdeadbeef (1+1)>
(64-bit values)
<.64 (0xdeadbeef << 32) (-1)>
(8-bit values)
<.8 0x00 0x0a 0xe4 0x2c 0x23 (0x10 + n)>
i.e. < > is list of values form, with size of each value as a sort of
parameter (defaulting to 32-bit, of course). I'm not sure I like that
particular syntax, it's just the first thing I came up with to
demonstrate the idea.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* [PATCH] Use SLB size from the device tree
From: Michael Neuling @ 2007-11-08 23:40 UTC (permalink / raw)
To: paulus; +Cc: Olof Johansson, linuxppc-dev, Will Schmidt
Currently we hardwire the number of SLBs but the PAPR says we export an
ibm,slb-size property to specify the number of SLB entries. This patch
uses this property instead of assuming 64 always. If no property is
found, we assume 64 entries as before.
This soft patches the SLB handler, so it won't change performance at
all.
Signed-off-by: Michael Neuling <mikey@neuling.org>
---
Paulus: for your 2.6.25 tree.
Olof: this touches the pasemi code, but I've not tested with one.
Will: this will interact with your SLB xmon patch, but is easy to
resolve.
arch/powerpc/kernel/prom.c | 11 +++++++++++
arch/powerpc/mm/hash_utils_64.c | 1 +
arch/powerpc/mm/slb.c | 3 +++
arch/powerpc/mm/slb_low.S | 5 +++--
arch/powerpc/platforms/pasemi/setup.c | 3 ++-
arch/powerpc/xmon/xmon.c | 2 +-
include/asm-powerpc/mmu-hash64.h | 1 +
include/asm-powerpc/reg.h | 6 ------
8 files changed, 22 insertions(+), 10 deletions(-)
Index: linux-2.6-ozlabs/arch/powerpc/kernel/prom.c
===================================================================
--- linux-2.6-ozlabs.orig/arch/powerpc/kernel/prom.c
+++ linux-2.6-ozlabs/arch/powerpc/kernel/prom.c
@@ -583,6 +583,16 @@ static void __init check_cpu_pa_features
ibm_pa_features, ARRAY_SIZE(ibm_pa_features));
}
+static void __init check_cpu_slb_size(unsigned long node)
+{
+ u32 *slb_size_ptr;
+
+ slb_size_ptr = of_get_flat_dt_prop(node, "ibm,slb-size", NULL);
+ if (slb_size_ptr != NULL) {
+ mmu_slb_size = *slb_size_ptr;
+ }
+}
+
static struct feature_property {
const char *name;
u32 min_value;
@@ -701,6 +711,7 @@ static int __init early_init_dt_scan_cpu
check_cpu_feature_properties(node);
check_cpu_pa_features(node);
+ check_cpu_slb_size(node);
#ifdef CONFIG_PPC_PSERIES
if (nthreads > 1)
Index: linux-2.6-ozlabs/arch/powerpc/mm/hash_utils_64.c
===================================================================
--- linux-2.6-ozlabs.orig/arch/powerpc/mm/hash_utils_64.c
+++ linux-2.6-ozlabs/arch/powerpc/mm/hash_utils_64.c
@@ -95,6 +95,7 @@ int mmu_vmalloc_psize = MMU_PAGE_4K;
int mmu_io_psize = MMU_PAGE_4K;
int mmu_kernel_ssize = MMU_SEGSIZE_256M;
int mmu_highuser_ssize = MMU_SEGSIZE_256M;
+u16 mmu_slb_size = 64;
#ifdef CONFIG_HUGETLB_PAGE
int mmu_huge_psize = MMU_PAGE_16M;
unsigned int HPAGE_SHIFT;
Index: linux-2.6-ozlabs/arch/powerpc/mm/slb.c
===================================================================
--- linux-2.6-ozlabs.orig/arch/powerpc/mm/slb.c
+++ linux-2.6-ozlabs/arch/powerpc/mm/slb.c
@@ -255,6 +255,7 @@ void slb_initialize(void)
static int slb_encoding_inited;
extern unsigned int *slb_miss_kernel_load_linear;
extern unsigned int *slb_miss_kernel_load_io;
+ extern unsigned int *slb_compare_rr_to_size;
/* Prepare our SLB miss handler based on our page size */
linear_llp = mmu_psize_defs[mmu_linear_psize].sllp;
@@ -268,6 +269,8 @@ void slb_initialize(void)
SLB_VSID_KERNEL | linear_llp);
patch_slb_encoding(slb_miss_kernel_load_io,
SLB_VSID_KERNEL | io_llp);
+ patch_slb_encoding(slb_compare_rr_to_size,
+ mmu_slb_size);
DBG("SLB: linear LLP = %04x\n", linear_llp);
DBG("SLB: io LLP = %04x\n", io_llp);
Index: linux-2.6-ozlabs/arch/powerpc/mm/slb_low.S
===================================================================
--- linux-2.6-ozlabs.orig/arch/powerpc/mm/slb_low.S
+++ linux-2.6-ozlabs/arch/powerpc/mm/slb_low.S
@@ -227,8 +227,9 @@ END_FW_FTR_SECTION_IFSET(FW_FEATURE_ISER
7: ld r10,PACASTABRR(r13)
addi r10,r10,1
- /* use a cpu feature mask if we ever change our slb size */
- cmpldi r10,SLB_NUM_ENTRIES
+ /* This gets soft patched on boot. */
+_GLOBAL(slb_compare_rr_to_size)
+ cmpldi r10,0
blt+ 4f
li r10,SLB_NUM_BOLTED
Index: linux-2.6-ozlabs/arch/powerpc/platforms/pasemi/setup.c
===================================================================
--- linux-2.6-ozlabs.orig/arch/powerpc/platforms/pasemi/setup.c
+++ linux-2.6-ozlabs/arch/powerpc/platforms/pasemi/setup.c
@@ -36,6 +36,7 @@
#include <asm/smp.h>
#include <asm/time.h>
#include <asm/of_platform.h>
+#include <asm/mmu.h>
#include <pcmcia/ss.h>
#include <pcmcia/cistpl.h>
@@ -295,7 +296,7 @@ static int pas_machine_check_handler(str
int i;
printk(KERN_ERR "slb contents:\n");
- for (i = 0; i < SLB_NUM_ENTRIES; i++) {
+ for (i = 0; i < mmu_slb_size; i++) {
asm volatile("slbmfee %0,%1" : "=r" (e) : "r" (i));
asm volatile("slbmfev %0,%1" : "=r" (v) : "r" (i));
printk(KERN_ERR "%02d %016lx %016lx\n", i, e, v);
Index: linux-2.6-ozlabs/arch/powerpc/xmon/xmon.c
===================================================================
--- linux-2.6-ozlabs.orig/arch/powerpc/xmon/xmon.c
+++ linux-2.6-ozlabs/arch/powerpc/xmon/xmon.c
@@ -2531,7 +2531,7 @@ static void dump_slb(void)
printf("SLB contents of cpu %x\n", smp_processor_id());
- for (i = 0; i < SLB_NUM_ENTRIES; i++) {
+ for (i = 0; i < mmu_slb_size; i++) {
asm volatile("slbmfee %0,%1" : "=r" (tmp) : "r" (i));
printf("%02d %016lx ", i, tmp);
Index: linux-2.6-ozlabs/include/asm-powerpc/mmu-hash64.h
===================================================================
--- linux-2.6-ozlabs.orig/include/asm-powerpc/mmu-hash64.h
+++ linux-2.6-ozlabs/include/asm-powerpc/mmu-hash64.h
@@ -180,6 +180,7 @@ extern int mmu_vmalloc_psize;
extern int mmu_io_psize;
extern int mmu_kernel_ssize;
extern int mmu_highuser_ssize;
+extern u16 mmu_slb_size;
/*
* If the processor supports 64k normal pages but not 64k cache
Index: linux-2.6-ozlabs/include/asm-powerpc/reg.h
===================================================================
--- linux-2.6-ozlabs.orig/include/asm-powerpc/reg.h
+++ linux-2.6-ozlabs/include/asm-powerpc/reg.h
@@ -695,12 +695,6 @@
#define PV_BE 0x0070
#define PV_PA6T 0x0090
-/*
- * Number of entries in the SLB. If this ever changes we should handle
- * it with a use a cpu feature fixup.
- */
-#define SLB_NUM_ENTRIES 64
-
/* Macros for setting and retrieving special purpose registers */
#ifndef __ASSEMBLY__
#define mfmsr() ({unsigned long rval; \
^ permalink raw reply
* OT: Strange delays / what usually happens every 10 min?
From: Florian Boelstler @ 2007-11-08 23:39 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
I am currently working on a MPC8540-based custom board, which runs Linux
2.6.15 (arch/ppc).
I set up a periodically running kernel thread, which is delayed for a
single jiffy using schedule_timeout() in an infinite loop. It is used to
measure delays between invocations of that thread. For measuring the
distance in time the PPC's time base lower half register is used
(obtained using get_cycles() defined in asm/timex.h).
The thread calculates the delay to the previous run and only outputs the
result if a new maximum value has been determined (in respect to all
previous cycles). Further the thread outputs a warning if a very "high"
delay was determined. I.e. a delay greater than 5ms.
While running that test driver a delay of about 10ms _exactly_ occurs
every 10 minutes.
The kernel is configured using CONFIG_HZ=1000 and CONFIG_PREEMPT.
The CCB is at 333MHz, whereas the TBR update rate is 333 MHz / 8, i.e.
41,625 MHz.
Apart of some kernel threads almost all user processes have been killed
during the test. Only SSH and a bash were running.
The kernel comes with compiled in CIFS support, some kernel debugging
features like soft-lockup detection and preemption debugging. I.e. ps
lists the kernel threads ksoftirqd, watchdog, events, khelper, kthread,
kblockd, pdflush, aio, cifsoplockd and cifsdnotifyd.
An appropriate userspace test tool based on nanosleep() determined the
same results like the kernel thread.
I also run tcpdump once to check whether some "random" network activity
might be the reason. While there havn't been any packets matching that
10 minutes interval, I got to know that a nearby Windows machine issues
ARP requests every 10 minutes (though not matching the 10ms delay).
Which leads to the question whether Linux does something similar in the
network sub system?
Thanks for any idea, I'm lost.
Cheers,
Florian
^ permalink raw reply
* [PATCH] [POWERPC] Optimize counting distinct entries in the relocation sections
From: Emil Medve @ 2007-11-08 23:36 UTC (permalink / raw)
To: paulus, rusty, ntl, sfr, behlendorf1, galak, linuxppc-dev,
linuxppc-embedded
Cc: Emil Medve
When a module has relocation sections with tens of thousands worth of entries,
counting the distinct/unique entries only (i.e. no duplicates) at load time can
take tens of seconds and up to minutes. The sore point is the count_relocs()
function which is called as part of the architecture specific module loading
processing path:
-> load_module() generic
-> module_frob_arch_sections() arch specific
-> get_plt_size() 32-bit
-> get_stubs_size() 64-bit
-> count_relocs()
(Not sure why the relocation tables could contain lots of duplicates and why
they are not trimmed at compile time by the linker. In some test cases, out of
35K relocation entries only 1.5K were distinct/unique)
The previous counting algorithm was having O(n^2) complexity. Basically two
solutions were proposed on the e-mail list: a hash based approach and a sort
based approach
The hash based approach is the fastest (O(n)) but the has it needs additional
memory and for certain corner cases it could take lots of memory due to the
degeneration of the hash. One such proposal was submitted here:
http://ozlabs.org/pipermail/linuxppc-dev/2007-June/037641.html
In this proposal, the symbol + addendum are hashed to generate a key and a
pointer to the relocation entry will be stored in it. The hash is implemented as
a linked list of memory pages with PAGE_SIZE / sizeof(Elfxx_Rela *) entries. In
case of collisions in all the existing pages, a new page is added to the list to
accommodate the new distinct relocation entry
For 32-bit PowerPCs with 4K pages, a page can accommodate 1K worth of pointers
to relocation entries. In the 35K entries scenario, as much/little of six (6)
pages could be allocated using 24K of extra memory during the module load
The sort based approach is slower (O(n * log n + n)) but if the sorting is done
"in place" it doesn't need additional memory. A proposal was submitted here:
http://ozlabs.org/pipermail/linuxppc-dev/2007-November/045854.html
(http://patchwork.ozlabs.org/linuxppc/patch?filter=default&id=14573)
In this proposal an array of pointers to the relocation entries is built and
then is sorted using the kernel sort() utility function. This is basically a heap
sort algorithm with a stable O(n * log n) complexity. With this counting the
distinct/unique entries is just linear (O(n)) complexity. The problem is the
extra memory needed in this proposal, which in the 35K relocation entries test
case it can be as much as 140K (for 32-bit PowerPCs; double for 64-bit). This is
much more then the memory needed by the hash based approach described
above/earlier but it doesn't hide potential degenerative corner cases
The current patch is a happy compromise between the two proposals above:
O(n + n * log n) performance with no additional memory requirements due to
sorting in place the relocation table itself
Signed-off-by: Emil Medve <Emilian.Medve@Freescale.com>
---
The style errors below are false positives because checkpatch understands the
Elfxx_Rela as operands instead of types
powerpc> scripts/checkpatch.pl 0001-POWERPC-Optimize-counting-distinct-entries-in-the.patch
ERROR: need consistent spacing around '*' (ctx:WxV)
#84: FILE: arch/powerpc/kernel/module_32.c:56:
+static uint32_t count_relocs(const Elf32_Rela *rela, uint32_t num)
^
ERROR: need consistent spacing around '*' (ctx:WxV)
#118: FILE: arch/powerpc/kernel/module_32.c:77:
+ const Elf32_Rela *x, *y;
^
ERROR: need consistent spacing around '*' (ctx:WxV)
#190: FILE: arch/powerpc/kernel/module_64.c:83:
+static uint64_t count_relocs(const Elf64_Rela *rela, uint64_t num)
^
ERROR: need consistent spacing around '*' (ctx:WxV)
#235: FILE: arch/powerpc/kernel/module_64.c:124:
+ const Elf64_Rela *x, *y;
^
total: 4 errors, 0 warnings, 0 checks, 225 lines checked
Your patch has style problems, please review. If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
arch/powerpc/kernel/module_32.c | 78 +++++++++++++++++++++++++++++-------
arch/powerpc/kernel/module_64.c | 85 ++++++++++++++++++++++++++++++--------
2 files changed, 130 insertions(+), 33 deletions(-)
diff --git a/arch/powerpc/kernel/module_32.c b/arch/powerpc/kernel/module_32.c
index 07a89a3..866637a 100644
--- a/arch/powerpc/kernel/module_32.c
+++ b/arch/powerpc/kernel/module_32.c
@@ -24,6 +24,7 @@
#include <linux/kernel.h>
#include <linux/cache.h>
#include <linux/bug.h>
+#include <linux/sort.h>
#include "setup.h"
@@ -52,24 +53,61 @@ void module_free(struct module *mod, void *module_region)
/* Count how many different relocations (different symbol, different
addend) */
-static unsigned int count_relocs(const Elf32_Rela *rela, unsigned int num)
+static uint32_t count_relocs(const Elf32_Rela *rela, uint32_t num)
{
- unsigned int i, j, ret = 0;
-
- /* Sure, this is order(n^2), but it's usually short, and not
- time critical */
- for (i = 0; i < num; i++) {
- for (j = 0; j < i; j++) {
- /* If this addend appeared before, it's
- already been counted */
- if (ELF32_R_SYM(rela[i].r_info)
- == ELF32_R_SYM(rela[j].r_info)
- && rela[i].r_addend == rela[j].r_addend)
- break;
+ int i;
+ uint32_t r_info, r_addend, _count_relocs;
+
+ _count_relocs = 0;
+ r_info = 0;
+ r_addend = 0;
+ for (i = 0; i < num; i++)
+ if (r_info != ELF32_R_SYM(rela[i].r_info) ||
+ r_addend != rela[i].r_addend) {
+ _count_relocs++;
+ r_info = ELF32_R_SYM(rela[i].r_info);
+ r_addend = rela[i].r_addend;
}
- if (j == i) ret++;
+
+ return _count_relocs;
+}
+
+static int relacmp(const void *_x, const void *_y)
+{
+ const Elf32_Rela *x, *y;
+
+ y = (Elf32_Rela *)_x;
+ x = (Elf32_Rela *)_y;
+
+ /* Compare the entire r_info (as opposed to ELF32_R_SYM(r_info) only) to
+ * make the comparison cheaper/faster. It won't affect the sorting or
+ * the counting algorithms' performance
+ */
+ if (x->r_info < y->r_info)
+ return -1;
+ else if (x->r_info > y->r_info)
+ return 1;
+ else if (x->r_addend < y->r_addend)
+ return -1;
+ else if (x->r_addend > y->r_addend)
+ return 1;
+ else
+ return 0;
+}
+
+static void relaswap(void *_x, void *_y, int size)
+{
+ uint32_t *x, *y, tmp;
+ int i;
+
+ y = (uint32_t *)_x;
+ x = (uint32_t *)_y;
+
+ for (i = 0; i < sizeof(Elf32_Rela) / sizeof(uint32_t); i++) {
+ tmp = x[i];
+ x[i] = y[i];
+ y[i] = tmp;
}
- return ret;
}
/* Get the potential trampolines size required of the init and
@@ -100,6 +138,16 @@ static unsigned long get_plt_size(const Elf32_Ehdr *hdr,
DEBUGP("Ptr: %p. Number: %u\n",
(void *)hdr + sechdrs[i].sh_offset,
sechdrs[i].sh_size / sizeof(Elf32_Rela));
+
+ /* Sort the relocation information based on a symbol and
+ * addend key. This is a stable O(n*log n) complexity
+ * alogrithm but it will reduce the complexity of
+ * count_relocs() to linear complexity O(n)
+ */
+ sort((void *)hdr + sechdrs[i].sh_offset,
+ sechdrs[i].sh_size / sizeof(Elf32_Rela),
+ sizeof(Elf32_Rela), relacmp, relaswap);
+
ret += count_relocs((void *)hdr
+ sechdrs[i].sh_offset,
sechdrs[i].sh_size
diff --git a/arch/powerpc/kernel/module_64.c b/arch/powerpc/kernel/module_64.c
index 75c7c4f..2ffe43f 100644
--- a/arch/powerpc/kernel/module_64.c
+++ b/arch/powerpc/kernel/module_64.c
@@ -24,6 +24,7 @@
#include <asm/module.h>
#include <asm/uaccess.h>
#include <asm/firmware.h>
+#include <linux/sort.h>
#include "setup.h"
@@ -79,27 +80,27 @@ static struct ppc64_stub_entry ppc64_stub =
/* Count how many different 24-bit relocations (different symbol,
different addend) */
-static unsigned int count_relocs(const Elf64_Rela *rela, unsigned int num)
+static uint64_t count_relocs(const Elf64_Rela *rela, uint64_t num)
{
- unsigned int i, j, ret = 0;
+ int i;
+ uint64_t r_info, r_addend, _count_relocs;
/* FIXME: Only count external ones --RR */
- /* Sure, this is order(n^2), but it's usually short, and not
- time critical */
- for (i = 0; i < num; i++) {
+ _count_relocs = 0;
+ r_info = 0;
+ r_addend = 0;
+ for (i = 0; i < num; i++)
/* Only count 24-bit relocs, others don't need stubs */
- if (ELF64_R_TYPE(rela[i].r_info) != R_PPC_REL24)
- continue;
- for (j = 0; j < i; j++) {
- /* If this addend appeared before, it's
- already been counted */
- if (rela[i].r_info == rela[j].r_info
- && rela[i].r_addend == rela[j].r_addend)
- break;
+ if (ELF64_R_TYPE(rela[i].r_info) == R_PPC_REL24) {
+ if (r_info != ELF64_R_SYM(rela[i].r_info) ||
+ r_addend != rela[i].r_addend) {
+ _count_relocs++;
+ r_info = ELF64_R_SYM(rela[i].r_info);
+ r_addend = rela[i].r_addend;
+ }
}
- if (j == i) ret++;
- }
- return ret;
+
+ return _count_relocs;
}
void *module_alloc(unsigned long size)
@@ -118,6 +119,44 @@ void module_free(struct module *mod, void *module_region)
table entries. */
}
+static int relacmp(const void *_x, const void *_y)
+{
+ const Elf64_Rela *x, *y;
+
+ y = (Elf64_Rela *)_x;
+ x = (Elf64_Rela *)_y;
+
+ /* Compare the entire r_info (as opposed to ELF64_R_SYM(r_info) only) to
+ * make the comparison cheaper/faster. It won't affect the sorting or
+ * the counting algorithms' performance
+ */
+ if (x->r_info < y->r_info)
+ return -1;
+ else if (x->r_info > y->r_info)
+ return 1;
+ else if (x->r_addend < y->r_addend)
+ return -1;
+ else if (x->r_addend > y->r_addend)
+ return 1;
+ else
+ return 0;
+}
+
+static void relaswap(void *_x, void *_y, int size)
+{
+ uint64_t *x, *y, tmp;
+ int i;
+
+ y = (uint64_t *)_x;
+ x = (uint64_t *)_y;
+
+ for (i = 0; i < sizeof(Elf64_Rela) / sizeof(uint64_t); i++) {
+ tmp = x[i];
+ x[i] = y[i];
+ y[i] = tmp;
+ }
+}
+
/* Get size of potential trampolines required. */
static unsigned long get_stubs_size(const Elf64_Ehdr *hdr,
const Elf64_Shdr *sechdrs)
@@ -133,6 +172,16 @@ static unsigned long get_stubs_size(const Elf64_Ehdr *hdr,
DEBUGP("Ptr: %p. Number: %lu\n",
(void *)sechdrs[i].sh_addr,
sechdrs[i].sh_size / sizeof(Elf64_Rela));
+
+ /* Sort the relocation information based on a symbol and
+ * addend key. This is a stable O(n*log n) complexity
+ * alogrithm but it will reduce the complexity of
+ * count_relocs() to linear complexity O(n)
+ */
+ sort((void *)sechdrs[i].sh_addr,
+ sechdrs[i].sh_size / sizeof(Elf64_Rela),
+ sizeof(Elf64_Rela), relacmp, relaswap);
+
relocs += count_relocs((void *)sechdrs[i].sh_addr,
sechdrs[i].sh_size
/ sizeof(Elf64_Rela));
@@ -343,7 +392,7 @@ int apply_relocate_add(Elf64_Shdr *sechdrs,
/* Simply set it */
*(u32 *)location = value;
break;
-
+
case R_PPC64_ADDR64:
/* Simply set it */
*(unsigned long *)location = value;
@@ -399,7 +448,7 @@ int apply_relocate_add(Elf64_Shdr *sechdrs,
}
/* Only replace bits 2 through 26 */
- *(uint32_t *)location
+ *(uint32_t *)location
= (*(uint32_t *)location & ~0x03fffffc)
| (value & 0x03fffffc);
break;
--
1.5.3.GIT
^ permalink raw reply related
* Re: [PATCH 3/4] Use embedded libfdt in the bootwrapper
From: David Gibson @ 2007-11-08 23:29 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <473392A3.4010203@freescale.com>
On Thu, Nov 08, 2007 at 04:50:11PM -0600, Scott Wood wrote:
> David Gibson wrote:
> >> How hard would it be to get libfdt to dynamically allocate any extra space
> >> it needs? This is a regression from the current flat device tree code...
> >
> > Uh.. it already does. Or rather, the shims in libfdt-wrapper.c do so,
> > when libfdt functions which can expand the tree report that they've
> > run out of room.
>
> Ah, good -- I was looking in libfdt itself, not the wrapper. Now if
> only we could get something similar into u-boot... maybe libfdt proper
> could accept an optional realloc() function pointer in fdt_init(), and
> eliminate the need for the caller to provide such a wrapper?
I've considered something like it (more likely an optional
realloc()ing wrapper layer that comes with libfdt).
For the bootwrapper itself, however, I'm still hoping to get rid of
malloc() entirely...
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [RFC] powermac: proper sleep management
From: Benjamin Herrenschmidt @ 2007-11-08 23:19 UTC (permalink / raw)
To: Scott Wood
Cc: linuxppc-dev list, Johannes Berg, David Woodhouse, linux-pm,
Paul Mackerras
In-Reply-To: <47336035.4020609@freescale.com>
On Thu, 2007-11-08 at 13:15 -0600, Scott Wood wrote:
> Johannes Berg wrote:
> > +/*
> > + * overrides the weak arch_suspend_disable_irqs in kernel/power/main.c
> > + *
> > + * XXX: Once Scott Wood's patch is merged, this needs to use the ppc_md
> > + * hooks that patch adds!
> > + */
> > +void arch_suspend_disable_irqs(void)
> > +{
> > +#ifdef CONFIG_PMAC_BACKLIGHT
> > + /* Tell backlight code not to muck around with the chip anymore */
> > + pmu_backlight_set_sleep(1);
> > +#endif
> > +
> > + /* Call platform functions marked "on sleep" */
> > + pmac_pfunc_i2c_suspend();
> > + pmac_pfunc_base_suspend();
>
> Shouldn't these be done from suspend methods of the relevant drivers?
> I don't understand why this needs to go in the disable IRQ hook.
The pmac_pfunc thing is low level platform stuff, no driver involved
there, this is the right place to do it.
As for the backlight bits, that could indeed be moved around I suppose,
I'd keep it there for now and look at cleaning the PMU driver
suspend/resume path in a second step.
Ben.
^ permalink raw reply
* Re: Kernel locks up after calling kernel_execve()
From: Benjamin Herrenschmidt @ 2007-11-08 23:20 UTC (permalink / raw)
To: Gerhard Pircher; +Cc: linuxppc-dev
In-Reply-To: <20071108214723.135260@gmx.net>
On Thu, 2007-11-08 at 22:47 +0100, Gerhard Pircher wrote:
> Hi,
>
> I tested my patches for the AmigaOne platform with the lastest 2.6.24-rc2
> kernel snapshot. The kernel runs through all initcalls, but locks up
> completely after calling INIT (/sbin/init) by kernel_execve(). Thus I
> couldn't capture any kernel oops or panic output. Also the magic sysrq
> key doesn't work. Enabling debug code for soft lockups and spinlock
> debugging didn't reveal any information.
> I'm not sure, but I think it is the same problem I had with all kernels
> >= 2.6.17. All of these kernels lock up shortly before or right at calling
> the init program (resp. as soon as the kernel forks some kernel theads).
> Any suggestions on how to track down this problem?
You don't have a HW debugger or anything like that ?
Ben.
^ permalink raw reply
* Re: [PATCH 3/4] Use embedded libfdt in the bootwrapper
From: Scott Wood @ 2007-11-08 22:50 UTC (permalink / raw)
To: Scott Wood, linuxppc-dev, Paul Mackerras
In-Reply-To: <20071108224051.GB18592@localhost.localdomain>
David Gibson wrote:
>> How hard would it be to get libfdt to dynamically allocate any extra space
>> it needs? This is a regression from the current flat device tree code...
>
> Uh.. it already does. Or rather, the shims in libfdt-wrapper.c do so,
> when libfdt functions which can expand the tree report that they've
> run out of room.
Ah, good -- I was looking in libfdt itself, not the wrapper. Now if
only we could get something similar into u-boot... maybe libfdt proper
could accept an optional realloc() function pointer in fdt_init(), and
eliminate the need for the caller to provide such a wrapper?
-Scott
^ permalink raw reply
* Re: [PATCH 3/4] Use embedded libfdt in the bootwrapper
From: David Gibson @ 2007-11-08 22:40 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20071108160839.GA4356@loki.buserror.net>
On Thu, Nov 08, 2007 at 10:08:39AM -0600, Scott Wood wrote:
> On Thu, Nov 08, 2007 at 02:36:03PM +1100, David Gibson wrote:
> > This patch incorporates libfdt (from the source embedded in an earlier
> > patch) into the wrapper.a library used by the bootwrapper. This
> > includes adding a libfdt_env.h file, which the libfdt sources need in
> > order to integrate into the bootwrapper environment, and a
> > libfdt-wrapper.c which provides glue to connect the bootwrappers
> > abstract device tree callbacks to the libfdt functions.
> >
> > In addition, this patch changes the various wrapper and platform files
> > to use libfdt functions instead of the older flatdevtree.c library.
>
> Won't we need to change the dtc invocation in the wrapper to reserve some
> space now?
>
> Speaking of which, it seems dtc still only supports setting the total size,
> as opposed to specifying the amount of additional space. It's still a bit
> crappy having to guess how much space to add, but it's better than needing
> to know how big the dtb will be without additional space.
>
> How hard would it be to get libfdt to dynamically allocate any extra space
> it needs? This is a regression from the current flat device tree code...
Uh.. it already does. Or rather, the shims in libfdt-wrapper.c do so,
when libfdt functions which can expand the tree report that they've
run out of room.
Ah... except that I haven't properly placed an fdt_open_into() with
possible expansion somewhere to make sure we can handle v16 or dtbs
with the blocks in unusual order.
I'll need to fix that before we merge.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ 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